Сквозные тесты в сравнении с юнит-тестами, следует ли разделять тесты?

Как правило, в нашей компании мы пишем комплексный тест для наших веб-сайтов / веб-приложений. Это означает, что мы получаем доступ к URL-адресу, заполняем форму, отправляем форму на другой URL-адрес и проверяем результаты на странице. Мы делаем это для проверки правильности формы, проверки правильности контекстных шаблонов HTML и т. Д.

Мы также используем его для косвенного тестирования базовой логики.

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

Мне интересно, имеет ли смысл такого рода разделение или это просто способ избежать написания тестов для небольших блоков кода?

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

Например, скажем, у вас есть три слоя, каждый из которых имеет пять возможных путей. Чтобы протестировать все пути через все приложение, потребуется 5 ³ сквозных теста, но вы можете протестировать все пути через каждый модуль с помощью только 5 · 3 модульных тестов. Если вы выполняете только сквозное тестирование, многие пути в конечном итоге остаются без внимания, в основном при обработке ошибок и граничных условиях.

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

После нескольких лет написания кода и работы над проектами я дам ответ на свой вопрос.

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

Если вы используете фреймворк, такой как Django или Rails (или ваши собственные пользовательские классы), у вас должен быть класс формы, который будет обрабатывать проверку формы. У вас также будут классы представления, которые отображают визуализированные шаблоны, а также формы и обрабатывают запросы GET и POST.

В конце теста вы бы:

1. получить URL
2. заполните форму с действительными данными
3. разместить форму на URL
4. проверьте, чтобы база данных была обновлена ​​или какое-либо действие было выполнено в результате правильной формы

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

Давайте попробуем это снова с юнит-тестами:

1. проверить метод GET view
2. проверить метод POST вида с фальшивой / фиктивной формой
3. проверить форму с правильными данными
4. проверить форму с неверными данными
5. проверить побочные эффекты формы

Используя модульные тесты, вы тестируете меньшие фрагменты кода, и эти тесты специфичны и их легче писать. Когда вы комбинируете это с TDD (Test Driven Development), вы получаете код более высокого качества.

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

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

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

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

На моей работе мы проводим Acceptance Test Driven Development без модульных тестов, которые звучат так же, как вы описали. Мы начали делать и со временем, и в конечном итоге исключили юнит-тестирование, что привело к тому, что затраты превысили наши выгоды.

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