Как организовать интеграционные тесты?

Question

При написании модульных тестов у меня обычно один тестовый класс на рабочий класс, поэтому моя иерархия будет выглядеть примерно так:

src/main
  -package1
    -classA
    -classB
  -package2
    -classC
src/test
  -package1
    -classATests
    -classBTests
  -package2
    -classCTests

Однако при проведении интеграционных тестов организация становится менее жесткой. Например, у меня может быть тестовый класс, который тестирует classA и classB вместе. Где бы вы это положили? А как насчет тестового класса, который тестирует classA, classB и classC вместе?

Кроме того, для интеграционных тестов обычно требуются внешние свойства или файлы конфигурации. Где вы их размещаете и используете ли вы какое-либо соглашение об именах для них?

Answer 1

Наши интеграционные тесты, как правило, организованы так же, как и наши спецификации. И они, как правило, собираются по категориям и / или функциям.

Answer 2

Я согласен с ответом f4.Такие тесты (уровень выше, чем UT) обычно не имеют корреляции с конкретными классами.Ваши тесты должны соответствовать требованиям и спецификациям проекта.

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

src/itest
  -package1 - corresponds to story#1
    -classA - test case1
    -classB - test case2
  -package2 - corresponds to story#1
    -classC - test case2
  -packageData - your common test data and utilities

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

Answer 3

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

Если у вас есть настоящие интеграционные тесты, то ассоциация с конкретными классами не имеет большого значения. Затем тесты классифицируются по предметным областям приложения (доменам) и типам функциональности. Например, домены - это заказы, отгрузки, счета-фактуры, разрешения и т. Д., А типы функций - это транзакции, Интернет, обмен сообщениями, пакетная обработка и т. Д. Их перестановки позволили бы вам в первую очередь понять, как организовать интеграционные тесты.

Answer 4

Может быть, создать каталог интеграционных тестов в src/test? Конечно, для интеграционных тестов разделение становится менее четким, но есть что-то, что объединяет группы A, B и C, нет? Я бы начал с этого и посмотрел, как идут дела. Сложно сразу найти идеальное решение, и решение «ОК» лучше, чем отсутствие решения.

Answer 5

Я обнаружил, что при выполнении TDD это не всегда так, что в модульных тестах существует соотношение 1: 1 между классами и тестами.Если вы сделаете это, вам будет трудно рефакторинг.Фактически, после некоторого рефакторинга я обычно получаю около 50% соединений 1: 1 и 50% тестов, которые можно связать с несколькими классами или кластерами тестов, которые ссылаются на один класс.попытаться доказать, что что-то работает или не работает.Это происходит либо тогда, когда вы беспокоитесь, потому что вам нужно что-то доставить, либо если вы обнаружили ошибку.Пытаться получить полное освещение от интеграционных тестов - это плохая идея (мягко говоря).

Самое главное, что тест должен рассказать историю.С точки зрения BDD: если у вас есть такое, то при этом это должно произойти.Тесты должны быть примерами того, как вы намерены использовать юнит, API, приложение, сервис, ...

Степень детализации и организация ваших тестов будут следовать из вашей основной сюжетной линии.Он не должен быть разработан с упрощенными правилами заранее.