Интеграционное тестирование - это может быть сделано правильно?

IMO, и у меня нет литературы, чтобы поддержать меня по этому поводу, но ключевое различие между нашими различными формами тестирования заключается в объеме,

• Модульное тестирование - это тестирование отдельных частей функциональности [обычно метод или класс с отслеживанием состояния]
• Интеграционное тестирование - это тестирование взаимодействия двух или более зависимых частей [обычно службы и потребителя, или даже подключения к базе данных, или подключения к какой-либо другой удаленной службе]
• Тестирование системной интеграции - это тестирование сквозная система [частный случай интеграционного тестирования]

Если вы знакомы с модульным тестированием, то неудивительно, что не существует такой вещи, как идеальный или «волшебный» тест. Интеграция и тестирование системной интеграции очень похоже на модульное тестирование, поскольку каждое из них представляет собой набор тестов, предназначенных для проверки определенного типа поведения.

Для каждого теста вы устанавливаете область, которая затем определяет ввод и ожидаемый результат. Затем вы выполняете тест и оцениваете фактическое значение ожидаемого.

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

К сожалению, это означает, что неожиданные сценарии будут возникать в циклах обеспечения качества [QA], Preproduction [PP] и Production [Prod]. На этом этапе ваши попытки воспроизвести эти сценарии в dev должны попасть в ваши пакеты интеграции и системной интеграции в виде автоматизированных тестов.

Надеюсь, это поможет, :)

ps: pet-peeve # 1: менеджеры или разработчики называют тесты интеграции и системной интеграции «модульными тестами» просто потому, что для их автоматизации использовались nUnit или MsTest ...

Вы можете просмотреть "Taming the Beast", презентацию Маркуса Клермонта и Джона Томаса об автоматизированном тестировании AJAX-приложений. YouTube Video

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

Большие тесты, таким образом, в основном направлены на то, чтобы убедиться, что сантехника правильная - действительно ли вкладка A находится в слоте A, а не в слоте B; согласны ли оба компонента, что длина измеряется в метрах, а не в футах, и так далее.

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

Что бы я сделал, чтобы проверить "настоящее" приложение: создание http запрос (вручную или автоматически) с некоторыми идентификаторами из базы данных и затем посмотрите в файловой системе, если файл был записан. Конечно это процесс можно автоматизировать, но все же: Разве это не дублирует логику тестирования?

Возможно, вы дублируете код, но вы не дублируете усилия. Модульные тесты и тесты интеграции служат двум разным целям, и обычно обе цели желательны в SDLC. Если возможно, перенесите код, используемый как для модульных, так и для интеграционных тестов, в общую библиотеку. Я бы также попытался создать отдельные проекты для ваших модульных / интеграционных тестов b / c ваши модульные тесты следует запускать отдельно (быстро и без зависимостей). Ваши интеграционные тесты будут более хрупкими и часто ломаться, поэтому у вас, вероятно, будет другая политика для запуска / поддержки этих тестов.

Это то, что называется «интеграция test »?

Да, действительно, это так.

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

Class OutFilevalidator {
    function isCorrect(fName, dataList) {
       // open file read data and
       // validation logic
}

Управление TDD с BDD покрывает большую часть этого за вас. Вы можете использовать Cucumber / SpecFlow с WatiR / WatiN. Для каждой функции у нее есть один или несколько сценариев, и вы работаете над одним сценарием (поведением) за раз, и когда он проходит, вы переходите к следующему сценарию, пока функция не будет завершена.

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

Вы, конечно, можете использовать интеграционное тестирование, как указывали другие.