Почему я должен и модульный тест и веб-тест (а не просто веб-тест)?

Question

Моя текущая позиция такова: если я тщательно тестирую свои приложения ASP.NET с помощью веб-тестов (в моем случае с помощью инструментов тестирования VS.NET'08 и WatiN, возможно) с охватом кода и широким спектром данных, я не нужно писать отдельные модульные тесты, потому что мой код будет тестироваться вместе с пользовательским интерфейсом на всех уровнях. Покрытие кода обеспечит выполнение каждого функционального фрагмента кода (или выявление неиспользуемого кода) и предоставит данные, которые будут охватывать все разумно ожидаемые условия.

Однако, если у вас другое мнение, я бы хотел знать:

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

2. Можете ли вы подробно объяснить свои причины с помощью конкретных примеров? Слишком часто я вижу ответы типа «это не то, для чего он предназначен» или «это способствует повышению качества» - что на самом деле не решает практический вопрос, с которым мне приходится сталкиваться, а именно: как я могу оправдать - с ощутимыми результатами - тратить больше время тестирования?

Answer 1

Модульное тестирование позволяет проводить более жесткие испытания производительности и значительно упрощает определение места возникновения узких мест. Для больших приложений производительность становится основной проблемой, когда 10 000 пользователей одновременно нажимают на метод, если этот метод занимает 1/100 секунды, возможно, из-за плохо написанного запроса к базе данных, потому что теперь некоторым пользователям приходится подождите до 10 секунд, пока страница загрузится. Я знаю, что лично я не буду так долго ждать загрузки страниц, а просто перейду в другое место.

Answer 2

Зависит от того, как работает архитектура приложения ASP.NET. Если веб-страницы просто подключают базовый уровень бизнес-логики или уровень доступа к данным, то модульные тесты, работающие независимо от модели состояния ASP.NET, быстрее разрабатываются и выполняются, чем аналогичные тесты WaitiN.

Недавно я разработал область устаревшего приложения ASP.NET в Visual Studio 2003 с NUnit в качестве среды тестирования. Принимая во внимание, что ранее тестирование включало в себя проработку тестов пользовательского интерфейса для обеспечения правильной реализации функциональности, 90% тестирования проводилось без взаимодействия с пользовательским интерфейсом.

Единственная проблема, с которой я столкнулся, - это оценка времени - одна из задач была запланирована в Trac: 1 день для доступа к данным / бизнес-логики и 2 дня для создания и тестирования пользовательского интерфейса. С NUnit, работающим над доступом к данным / бизнес-логикой, время для этой части разработки сократилось с 1 дня до 2 дней. Разработка интерфейса была сокращена до одного 1/2 дня.

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