Когда мне следует писать интеграционные тесты?

В соответствии с правилами TDD модульные тесты написаны перед рабочим кодом, но как насчет интеграционных тестов, которые осуществляют взаимодействие между конкретными (не имитированными) проводными объектами?

Должны ли они быть написаны до модульных тестов или после производственного кода только для проверки «проводки»?

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

Книга Rspec , среди других ресурсов BDD, предлагает такой цикл:

По сути, этот процесс:

While behaviour required
    Write an integration test for a specific behaviour
    While integration test failing
        Write a unit test to fulfil partial behavior
        While unit test failing
            Write code to make unit test pass
        Commit
        While refactoring can be done
            Refactor
            While unit test failing
                Write code to make unit test pass
            Commit
    Push

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

Тем не менее, иметь в виду идеальный процесс это здорово. Это дает вам точку для компромисса.

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

Зачем? Позвольте мне написать, как я вижу оба вида тестов:

1. Модульные тесты - В дополнение к Википедии и всем известной информации, модульные тесты помогают вам сузить ваш дизайн , улучшить вашу модель, отношения. Процесс прост: как только вы начинаете вводить новый проект / новый компонент, большую часть времени вы делаете какой-то PoC . Когда вы закончите, у вас всегда будут длинные методы, длинные классы, некогерентные методы и классы и т. Д.

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

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

   Это действительно важно, так как иногда вам говорят, что ваш API не имеет смысла извне.

Ну, что произойдет, когда я напишу модульные тесты и интеграционные тесты позже?

У меня хорошие классы, понятный дизайн, хороший конструктор, короткие и согласованные методы, готовность к IoC и т. Д. После того, как я передал свой класс / API какому-то потребителю, например разработчику из группы интеграции или графического интерфейса, он не смог использовать мой API, так как это кажется нелогичным , странно. Он был просто смущен. Поэтому я восстановил API в соответствии с его точкой зрения, но также потребовалось переписать много тестов, потому что я был вынужден изменить методы, а иногда и процесс использования API.

Ну, что произойдет, когда я напишу интеграционные и модульные тесты позже?

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

Какой мой совет?

Я изучил следующий поток:

1. Разработайте базовый каркас вашего кода
2. Напишите интеграционные тесты, которые говорят, имеет ли это смысл с точки зрения потребителя. Базового варианта использования пока достаточно. Тест явно не работает.
3. Напишите код вместе с модульными тестами для каждого класса.
4. Напишите остаток / отсутствие интеграционных тестов. Было бы лучше реализовать эти тесты в # 3, как вы улучшаете свой код.

Обратите внимание, что я сделал небольшую презентацию о модульном / интеграционном тестировании, см. Слайд № 21, где описан скелет.

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

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

Я склонен рассматривать интеграционные тесты как очень похожие на модульные тесты. В этом я рассматриваю подмножество кода как черный ящик. Так что интеграционные тесты - это просто большая коробка.

Я предпочитаю писать их перед производственным кодом. Это имеет то преимущество, что помогает мне вспомнить, какие части я еще не подключил, или что я немного изменил детали взаимодействия объектов.

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

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

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

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

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

Вы можете найти примеры такого подхода здесь: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (6-й абзац) http://blog.8thlight.com/eric- кузнец / 2011/10 / 27 / Thats-не-yours.html

Итак, я собирался принять первый ответ, но он был удален.
Подводя итог
в данной итерации:

1. Написать юнит-тест
2. Написать производственный код
3. Написать интеграционные тесты для тестирования взаимодействия

Имейте в виду интеграционное тестирование при 1 и 2, чтобы гарантировать тестируемость на уровне интеграции.

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

Модульные тесты тестируют отдельные блоки кода в вашем проекте.
Интеграционные тесты проверяют, как ваш код взаимодействует с другим кодом: другими словами, они тестируют интерфейс вашего кода.

Напишите модульные тесты при разработке кода за интерфейсом.
Напишите интеграционные тесты при разработке интерфейса или любого кода, который реализует интерфейс.

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

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