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

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

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

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

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


unit-testing integration-testing architecture
person Asaf David    schedule 11.02.2010    source источник

Ответы (5)


arrow_upward
2
arrow_downward

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

person f4.    schedule 11.02.2010
comment
Этот ответ совсем не помогает и не заслуживает одобрения :-| - person t3chb0t; 24.06.2016

arrow_upward
2
arrow_downward

Я бы согласился с ответом 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

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

person Community    schedule 18.11.2010

arrow_upward
1
arrow_downward

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

person EightyEight    schedule 11.02.2010

arrow_upward
1
arrow_downward

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

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

person topchef    schedule 12.02.2010

arrow_upward
1
arrow_downward

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

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

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

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

person iwein    schedule 17.11.2010