Комментарии 7
три этапа: подготовка (setup), действие (act) и проверка (verify).
Обычно про них говорят как о "трёх А": "Arrange", "Act", и "Assert".
На словах идея TDD красивая - я сам люблю юнит-тесты и всегда их пишу. Но. В реальности чистое TDD сразу же напарывается на проблему зависимостей. Чтобы заменить в тесте зависимости мок-объектами надо уже их знать и знать сценарии их использования тестируемым объектом. А для этого, как правило, надо уже иметь код самого объекта. Поэтому лично я с TDD не заморачиваюсь а просто параллельно разрабатываю объект и сразу тесты к нему.
...
Спасибо за статью!
Расскажите, в какой момент у вас в команде к работе подключаются тестировщики и как происходит работа с вашими юнит-тестами? Трогают ли они их, или пишут потом свои интеграционные?
Еще интересно, проверяете ли вы потом юниты на тестовых данных(с переключением environment) или так и оставляете на моках?
Юнит-тесты вообще "трогать" не надо, (разве что локально на машине разработчика) они должны быть встроены в процесс CI, чтобы "красный" код даже в общую "develop" ветку никогда не попал.
Добрый день!
Тестировщики у нас к работе подключаются после завершения разработки. Тестировщики не трогают юнит-тесты, пишут только свои интеграционные.
Юниты мы так и оставляем на моках, в нашем случае этого всегда достаточно .
Следующий шаг: осознать, что TDD — не про тестирование, а про разработку; и пишутся не тесты, а спецификации.
Разработка через тестирование. Совместное использование JUnit 5 и Mockito