Тут допускаю, что опыт у всех разный Насчет юнит и интеграционных тестов - это все же две разные сущности, которые не исключают друг друга. Более того, юнит тесты позволят покрыть, условно, 500 сценариев бизнес-логики без похода в базу, что сильно облегчит разработку и избавит от необходимости поднимать каждый раз весь контур. Интеграции - это очень важно и их обязательно нужно проверять, вы правы, но с наличием юнит тестов вы сильно сократите количество интеграционных (в этом примере потребуется добавить только кейсы на запись в бд)
Тут все правда, увы, количество мутаций очень большое) Если говорить о рабочих проектах и внедрении регулярных проверок - наверное, лучше не блокировать изменения, а гонять с какой-то периодичностью на мастере
Спасибо за комментарий! Пример тут и правда сильно упрощен, чтобы просто визуализировать смысл содержания. Основное, что хотелось показать - что результатов вызова метода может быть несколько и привычный нам тест может покрыть не всю логику:)
Про вызов функции - спасибо за замечание, и правда неудачная формулировка.
У вас очень хороший подход, так и разработчик сразу видит более точные требования и оценка задаче будет более честная:) А ресурсов QA хватает на все задачки?
Тут допускаю, что опыт у всех разный
Насчет юнит и интеграционных тестов - это все же две разные сущности, которые не исключают друг друга. Более того, юнит тесты позволят покрыть, условно, 500 сценариев бизнес-логики без похода в базу, что сильно облегчит разработку и избавит от необходимости поднимать каждый раз весь контур.
Интеграции - это очень важно и их обязательно нужно проверять, вы правы, но с наличием юнит тестов вы сильно сократите количество интеграционных (в этом примере потребуется добавить только кейсы на запись в бд)
Тут все правда, увы, количество мутаций очень большое)
Если говорить о рабочих проектах и внедрении регулярных проверок - наверное, лучше не блокировать изменения, а гонять с какой-то периодичностью на мастере
Есть такая статья на эту тему, надеюсь, будет полезна - Мутационное тестирование: опыт внедрения на 1500 сервисов
У нас используется доработка этой библиотеки go-mutesting
Тут форк, который можно использовать - https://github.com/avito-tech/go-mutesting
Спасибо за комментарий!
Пример тут и правда сильно упрощен, чтобы просто визуализировать смысл содержания.
Основное, что хотелось показать - что результатов вызова метода может быть несколько и привычный нам тест может покрыть не всю логику:)
Про вызов функции - спасибо за замечание, и правда неудачная формулировка.
У вас очень хороший подход, так и разработчик сразу видит более точные требования и оценка задаче будет более честная:) А ресурсов QA хватает на все задачки?