Стоит ли разделять юнит-тесты и интеграционные тесты?

17

Я должен написать модульные тесты и интеграционные тесты для проекта.

  • Все тесты должны быть помещены в одну папку тестов ?
  • Или юнит-тесты и интеграционные тесты должны находиться в отдельной папке тестов ?
  • Или я должен даже поместить их в отдельные проекты ?

Если я буду держать их вместе, есть ли какие-либо преимущества или недостатки этого подхода?

architecture unit-testing integration-tests Ахмед Рагхеб
источник
1
Если вы работаете в среде CI, важно, чтобы их можно было легко идентифицировать (по атрибутам и т. Д.), Поскольку интеграционные тесты не всегда выполняются на сервере сборки.
Робби Ди
3
Связанный: Тестирование: единица против интеграции против других, зачем нужно разделение?
Mouviciel

Ответы:

18

В целом: да, вы должны поместить интеграционные тесты и модульные тесты в разные папки. Часто программисты не проводят четкой грани между этими двумя типами тестов и просто пишут какой-либо тип теста, который будет полезен. Но интеграционные тесты, как правило, медленнее, потому что они часто включают в себя:

  • Запросы к базе данных
  • Сетевые запросы
  • Поведение, зависящее от времени
  • Большие объемы данных

В отличие от этого, модульное тестирование могло бы подделать любые дорогостоящие операции, поэтому модульные тесты, как правило, выполняются быстро (на самом деле, самой медленной частью выполнения теста часто является сама структура теста).

Когда программист работает в системе, он находится в цикле редактирования-тестирования. Чем быстрее они получат тестовую обратную связь и чем короче цикл, тем более продуктивными они могут быть. Таким образом, мы хотим запустить только важный тест, который завершится быстро. Полный набор тестов будет выполняться только как часть процесса обеспечения качества, например, на сервере CI.

Это означает, что большие тестовые наборы должны быть классифицированы. Можно ли выбирать модульные тесты только для определенного компонента? Можем ли мы исключить медленные тесты? Один простой способ сделать это - поддерживать разные наборы тестов в разных каталогах. Если у вас очень мало тестов, один каталог также будет в порядке, если программист может легко выбрать подмножество тестов.

Все, что позволяет программисту быстро получать обратную связь, хорошо. Самый полный набор тестов не имеет значения, если он не выполняется регулярно.

Дальнейшее чтение:

Амон
источник
Разделяя папки, держите ли вы каждую из них в том же пакете, что и рабочий код (чтобы вы могли тестировать защищенные методы)? Например, вы делаете модуль maven для модульных тестов и другой модуль maven для интеграционных тестов. Таким образом, вы можете разделить их и по-прежнему легко тестировать защищенные методы.
ihebiheb
@ihebiheb В Java использование видимости пакетов довольно неодобрительно. В некоторых случаях может быть полезно использовать его и получить доступ к этим API из модульных тестов. Но в целом это не нужно. Тесты в стиле интеграции никогда не нуждаются в доступе к закрытым членам пакета. То, стоит ли помещать тесты в отдельный проект Maven, зависит от того, как вы хотите их запускать и развертывать. Я не вхожу в Java / Maven, чтобы иметь возможность рассказать вам, что здесь разумно.
Амон