отловят, вопрос: стоит ли оставшаяся часть отдельного слоя тестов, или, может, за те же деньги получше покрыть фичи e2e-тестами? Потом, можно генерировать клиентов из спеки апи, сваггера, скажем. Родной сваггер-кодоген, правда, плохой, так что только свой саппортить. Ну и саму спеку можно использовать, чтобы контракты выражать поточнее. Скажем, какую проблему можно найти с помощью таких тестов на совместимость апи-клиент: есть интовое поле, сервер сует туда -1, клиент не ожидает. Можно очень хорошо покрыть это "тестами на совместимость", буквально руками учтя значимые частные случаи - это больно, пачка тестов на каждый филд. Можно делать что-то с пространством состояний, не модел чекинг - тоже больно - а, скажем, в духе property-based testing. Можно сразу захватывать контракты в спеке ("здесь только неотрицательный инт") и корректным образом хэндлить контракты в своем кодогене - самый дешевый, наверное, вариант с хорошим выхлопом, не надо реверсить контракты в тестах.
я вот как раз смотрю есть ли альтернативы полному е2е тестингу. не хочется тащить селениум или подобное. так бы логику фронта проверил чисто на фронте, логику бекенда так же отдельно, а протокол между ними какими-то контрактными тестами. но я еще не понял хорошо ли так делать
Обсуждают сегодня