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

Question

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

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

Наш проект выполняется по итерационной инкрементальной модели.

Answer 1

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

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

• Отменить устаревшие тесты - Иногда бессмысленно пытаться обновить от сотен до тысяч строк тестов, если они, по сути, являются неточными или неуместными. Откажитесь от тестов немедленно. Не игнорируйте их, не комментируйте их. Удалите их полностью.
• Написание тестов для новой функциональности - Любая новая функциональность все еще нуждается в модульном тестировании и написании для модульной проверки.
• Написание тестов для исправлений ошибок - При регрессионном тестировании приложения может быть важно убедиться, что исправления ошибок имеют модульные тесты, гарантирующие, что ошибка была исправлена.
• К черту покрытие кода - Я уверен, что это может заработать несколько отрицательных голосов, но есть тонкая грань между обеспечением функциональности и использованием тестов в качестве оправдания для задержки работы . Внимание должно быть сосредоточено на обеспечении основных функциональных возможностей, а не на любом проценте покрытия произвольного кода.

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

Answer 2

Один из ответов SO на вопрос «об ограничениях модульного тестирования» заключался в том, что модульное тестирование становится запутанным, когда оно используется для тестирования чего-либо, связанного с INTEGRATION, а не с функцией. Подключение к внешним службам и их использование (база данных, SSH-соединение с другим сервером и т. Д.) И пользовательские интерфейсы - вот два примера.

Это не значит, что вы НЕ МОЖЕТЕ использовать модульное тестирование для этих вещей, просто трудность, связанная с охватом всех баз, делает использование этого метода тестирования не стоящим, за исключением случаев, когда надежность имеет первостепенное значение.

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

Answer 3

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

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

Answer 4

На самом деле существует четыре уровня тестирования, 3 из которых могут включать сценарии, а первый - нет.

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

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

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

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

Answer 5

Две разные вещи

• Модульные тесты - Разработчик - проверьте правильность кода
• Приемочные испытания - Заказчик / QA / BA - убедитесь, что разработан правильный код.

Две категории должны быть различны, и обе играют одинаково важную роль. Отбрасывание одной не сулит ничего хорошего. Тестовые сценарии, как вы упомянули, попадают во вторую категорию. Я бы порекомендовал что-то вроде FIT / Fitnesse для этой цели. Если это невозможно, тогда используйте инструменты стиля test-scripts / record-replay. Но не выбрасывайте хорошие юнит-тесты ... что вы подразумеваете под "стоимость обслуживания тестов стала дорогой"?

Answer 6

Я предполагаю, что усилия по обслуживанию ваших модульных тестов возрастают, потому что архитектуре вашего приложения было разрешено развалиться. Поскольку никто, кроме вас, на самом деле не знает, что находится в вашем коде, вы можете применить метод Five whys, чтобы решить, в чем заключается ваша настоящая, существенная, корневая проблема. Модульные тесты IME никогда не должны быть дорогостоящими в обслуживании, если вы используете архитектуру на основе интерфейсов с высокой степенью развязки.