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

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

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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

Я согласен с ответом 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

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