Что делать с длительными модульными тестами?

Для меня это не похоже на модульные тесты, а скорее на функциональные тесты. Это нормально, автоматизация функционального тестирования — это хорошо, но функциональные тесты часто бывают медленными. Они тестируют всю систему (или большие ее части).

Модульные тесты имеют тенденцию быть быстрыми, потому что они тестируют одну вещь изолированно от всего остального. Если вы не можете тестировать что-то изолированно от всего остального, вам следует подумать о том, что ваш код слишком тесно связан.

Можете ли вы сказать, какие тесты у вас есть, которые являются модульными тестами (тестирование только 1 вещи) по сравнению с функциональными тестами (тестирование 2 или более вещей одновременно)? Какие из них быстрые, а какие медленные?

Вы можете разделить свои тесты на две группы, одну для коротких тестов и одну для длительных тестов, и запускать длительные тесты реже, запуская короткие тесты после каждого изменения. Помимо этого, имитация ответов веб-сервера и других запросов, которые делает ваше приложение, приведет к более короткому тестовому прогону.

Я бы рекомендовал комбинированный подход к вашей проблеме:

• Часто запускайте подмножество тестов, близких к коду, в который вы вносите изменения (например, тесты из того же пакета, модуля и т. п.). Реже запускайте тесты, более удаленные от кода, над которым вы сейчас работаете.
• Разделите свой набор как минимум на два: быстрые и медленные тесты. Чаще запускайте быстрые тесты.
• Подумайте о том, чтобы некоторые тесты с меньшей вероятностью отказа выполнялись только автоматическим сервером непрерывной интеграции.
• Изучите методы повышения производительности ваших тестов. Самое главное, заменив доступ к медленным системным ресурсам более быстрыми подделками. Например, использовать в памяти потоки вместо файлов. Заглушка/макет http-доступа. и т.п.
• Узнайте, как использовать методы разрушения зависимостей с низким уровнем риска, подобные тем, которые перечислены в (настоятельно рекомендуемой) книге «Эффективная работа с устаревшим кодом». Это позволяет вам эффективно сделать ваш код более тестируемым без применения рефакторинга с высоким риском (часто путем временного ухудшения фактического дизайна, например, нарушения инкапсуляции, до тех пор, пока вы не сможете провести рефакторинг для улучшения дизайна с помощью страховочной сети тестов).

Одна из самых важных вещей, которую я усвоил из упомянутой выше книги: волшебства нет, работа с унаследованным кодом это боль и всегда будет болью. Все, что вы можете сделать, это принять этот факт и сделать все возможное, чтобы постепенно выбраться из беспорядка.

Во-первых, это не модульные тесты.

Нет особого смысла запускать такие функциональные тесты после каждого небольшого изменения. После значительного изменения вы захотите запустить свои функциональные тесты.

Во-вторых, не бойтесь издеваться над Http-частью приложения. Если вы действительно хотите провести модульное тестирование приложения, это ДОЛЖНО. Если вы не хотите этого делать, вы потратите гораздо больше времени, пытаясь проверить свою фактическую логику, ожидая возврата HTTP-запросов и пытаясь настроить данные.

Я бы оставил ваши тесты уровня интеграции, но стремился создавать настоящие модульные тесты. Это решит ваши проблемы со скоростью. Реальные модульные тесты не взаимодействуют с БД или HTTP.

Я всегда использую категорию для «LongTest». Эти тесты выполняются каждую ночь, а не днем. Таким образом, вы можете значительно сократить время ожидания. Попробуйте: классифицируйте модульное тестирование.

Похоже, вам также может понадобиться управлять ожиданиями среди команды разработчиков.

Я предполагаю, что люди делают несколько сборок в день и должны запускать тесты после каждой сборки. Возможно, мы будем рады изменить график тестирования, чтобы запустить сборку с тестами во время обеда, а затем еще одну ночью.

Я согласен с Брэдом, что это похоже на функциональные тесты. Если бы вы могли разделить код, это было бы здорово, но до тех пор я бы переключился на менее частое тестирование.