Теперь покрыты все кейсы и роуты без изменения какой-либо логики в коде. Так ещё и удобство - в дальнейшем достаточно будет добавить роут к списку, чтобы не писать тест на каждый новый роут отдельно (специфические случаи, конечно же всё равно будут тестироваться отдельно).
Вопрос: плюсы и минусы использования циклов для формирования тестов? Ну, из очевидного - параметры - они не всегда универсальные.
Не очень понятно, что тут имеется в виду под циклом. > достаточно будет добавить роут к списку Но у разных роутов обычно разные тесты. или все тесты сводятся к сравнению ответа запроса при определённом запросе?
"Не очень понятно, что тут имеется в виду под циклом" Пример: const exchanges: = { coinbase: [ 'default', 'sandbox' ], exmo: [ 'default', 'margin' ], huobi: [ 'default', 'aws' ], nicehash: [ 'default' ], poloniex: [ 'default', 'futures' ], ... }; const routes = [ 'getAccountsData', 'getKChartData', 'getTickersData', ... ]; Object.keys( exchanges ).forEach( exchange => { describe( `${ exchange } should reply 500 if uid is not present in request`, () => { exchanges[ exchange ].forEach( type => { routes.forEach( route => { test( ... ); } ); } ); } ); } ); "или все тесты сводятся к сравнению ответа запроса при определённом запросе?" Ну, базовый набор тестов на 500, наличие отсутствие необходимых заголовков в ответе, 404 и прочие общие для всех роутов сценарии ответов.
Вообще вызывают вопросы тесты, которые проверяют, что бек кидает 500...
Почему? Например кейс, что указанный параметр не поддерживается. В этом случае бек ничего трогать не должен и выкидывает ошибку.
Потому что 500 означает ошибку сервера
Это дефолт у Фастифая, выкидывать такие статусы в таких случаях 🤷♂️
в тестах ты должен проверить работу своего кода, а не стороннего сервиса это уже другие тесты
это на ошибки валидации, знаю.
Обсуждают сегодня