Как организовать интеграционные тесты?
При записи модульных тестов у меня обычно есть один тестовый класс в производственном классе, таким образом, моя иерархия посмотрит что-то как этот:
src/main
-package1
-classA
-classB
-package2
-classC
src/test
-package1
-classATests
-classBTests
-package2
-classCTests
Однако при выполнении интеграционных тестов организация становится менее твердой. Например, у меня может быть тестовый класс, который тестирует classA и classB в соединении. Куда Вы поместили бы его? Что относительно тестового класса, который тестирует classA, classB и класс вместе?
Кроме того, интеграционные тесты обычно требуют внешних свойств или конфигурационных файлов. Куда Вы размещаете их, и Вы используете какое-либо соглашение о присвоении имен для них?
3 ответа
Наши интеграционные тесты обычно организованы так же, как и наши спецификации. И они, как правило, собираются по категориям и / или функциям.
Может быть, создать каталог интеграционных тестов в src / test ? Конечно, для интеграционных тестов разделение становится менее четким, но есть что-то, что группирует A, B и C вместе, не так ли? Я бы начал с этого и посмотрел, как идут дела. Трудно сразу придумать идеальное решение, и «ОК» лучше, чем отсутствие решения.
Похоже, что ваши интеграционные тесты являются модульными тестами более высокого уровня, поскольку вы все равно привязываете их к одному или нескольким классам. Попробуйте выбрать из группы класс, который зависит от всех остальных (транзитивно), и связать тест с таким классом.
Если у вас настоящие интеграционные тесты, то ассоциация с конкретными классами не имеет большого значения. Затем тесты классифицируются по предметным областям приложения (доменам) и по типам функциональности. Например, доменами являются заказы, поставки, счета, права и т.д., а типами функциональности - транзакционные, веб-, обмен сообщениями, пакетные и т.д. Их перестановки дадут вам хороший первый срез того, как организовать интеграционные тесты.