/R
так, а что ты подразумеваешь под контракт тестом?
Size: a a a
2021 July 19
K
В
его же используются для тестирования микросервисов, когда должен приходить определенный набор данных в реквестах\респонсах на микросервис + корректное отрабатывания некорректных данных.
/R
а интеграционное тестирование зачем?
K
Идея отличная. Собественно, для того оно и придумано. Правда из моей практики - реализовать нормальный процесс сильно сложнее. Если без супер-жестких кволити-гейтов, которые анально карают за сломанные контракты или несоответствие им.
В
Как я понял, контрактное тестирование больше придумано для тестирования микросервисов.
А я предлогал это использовать для более быстрого разработки функционала на беке и фронте(посчитать их тоже микросервисами)
А я предлогал это использовать для более быстрого разработки функционала на беке и фронте(посчитать их тоже микросервисами)
DA
Запускать фронт против контракта вместо бекенда? в теории мысль звучит очень интересно
S1
по сути это мок всего бэка. очко сотрётся мне кажется
IB
есть какая-то толковая статья про контрактное? я все еще не вкурил с прошлого раза)
контракт - это что, мок?
контракт - это что, мок?
DA
Это пара: мок и тесты на него. Мок для клиента и тесты для сервера
DA
Он гарантирует что то что замокано - нормально протестировано
IB
а кто гарантирует что нормально замокано?)
DA
И то что протестировано - нормально замокано ))))
IG
Другой контракт)
DA
Этот же
DA
А что не протестировано и не замокано - того нет в контракте: оно упущено
В
не понял вопрос, но попробую обьяснить что я хочу донести.
у нас например пока бек не сделает АПИ с рабочей логикой, у нас фронт просто верстает и ждет, а я предлагаю использовать подход контрактного тестирования для этой связки.
То есть бек с фронтом обсуждают дизайн и логику, договориваются что получать\отправлять и сразу же работаю, у фронтов замоканные обьекты свои, у бека пока ничего.
у нас например пока бек не сделает АПИ с рабочей логикой, у нас фронт просто верстает и ждет, а я предлагаю использовать подход контрактного тестирования для этой связки.
То есть бек с фронтом обсуждают дизайн и логику, договориваются что получать\отправлять и сразу же работаю, у фронтов замоканные обьекты свои, у бека пока ничего.
IB
у нас как-то разрабы очень плохо относятся к мокам. Типа реальный сервис делает одно, а мок - другое и что тестируется - большой вопрос. И как актуализировать мок
DA
Ну да, звучит как то что можно решить контрактом. К удивлению, я ни разу не видел как это решали на практике контрактом. И сам таким никогда не занимался. Но в угаре временами мне приходит в голову такая мысль. Но меня потом отпускает.
S1
ну вообще так и делается частенько. ну когда время есть