В моем приложении десятки компьютеров будут работать с визуальным ярусом. Бизнес-уровень будет размещен на сервере, который также содержит базу данных.На трехуровневое приложение требуется единичное тестирование на визуальном уровне?
Модульное тестирование действительно необходимо на моем визуальном уровне, который в основном будет содержать призывы к бизнес-уровню? Любой конкретный случай?
UI-тесты редко называют модульными испытаниями, потому что действительно сложно проверить единицу кода. Раньше мы называли их интеграционными тестами, испытаниями на работоспособность, функциональными испытаниями или приемочными испытаниями. По сути, они проверяют, что система (а не единица кода) работает после ее развертывания. Но это зависит от того, чего вы пытаетесь достичь.
Независимо от того, следует ли автоматизировать тесты пользовательского интерфейса, зависит от нескольких факторов. Почасовая ставка разработчиков часто намного больше, чем у QA. Поэтому нужно взглянуть на то, какое значение автоматические тесты, написанные разработчиком, предоставляют всей организации. Час, который разработчик тратит на письменные тесты, может лучше потратить на добавление стоимости в систему. Однако QA очень редко смотрят на систему с точки зрения единицы, оставляя их в невыгодном положении.
Однако разработчики обладают скрытым знанием системы и поэтому могут значительно повысить качество, если они пишут тесты. Тесты действуют как документация для других разработчиков и выражают намерение. Более раннее выявление проблем является более дешевым и наиболее убедительной мотивацией для написания тестов для разработчиков.
Таким образом, вам нужно найти баланс между ними. Разработка и поддержка любых тестов UI требует много времени и сложностей, особенно в распределенных средах. Тесты UI часто ненадежны и легко ломаются. Вы должны рассмотреть вопрос об обеспечении среды, посеве базы данных и т. Д. Вам также необходимо рассмотреть, достаточно ли ресурсов для запуска автоматических тестов. Он также становится дорогим.
Вы можете сократить расходы, передав их на аутсорсинг или сделав это вручную. Последнее может быть быстрее повторять каждый раз, чем проходить цикл создания, ведения, запуска и диагностики автоматических тестов пользовательского интерфейса.
При этом, если ваш пользовательский интерфейс является стабильным, очень полезно иметь пару приемочных испытаний, чтобы проверить работоспособность системы. Посмотрите на 20% -ные функции, которые используются 80% времени, и те функции в пользовательском интерфейсе, которые, если они не работают, будут бесполезны. По крайней мере, вы будете знать, что 20% всех, включая вашего босса или клиента, заботятся о работе, прежде чем давать QA или клиенту для тестирования.
Тестирование ради тестирования никогда не является подходящей причиной для тестирования.
единичный тест необходим на любом уровне, который вы развертываете. Целостность всего вашего кода должна поддерживаться модульными тестами независимо от уровня.
«... на моем визуальном уровне, который в основном будет содержать вызовы бизнес-уровня ...» означает, что какой-то код будет развернут на уровне пользовательского интерфейса. в результате, хорошая практика - разработать интеграционные тесты для этого кода, а также использовать насмешливую структуру для разработки настоящих модульных тестов. он не указал технологии, но приложение MVC, например, будет иметь логику просмотра на стороне клиента javascript и контроллеры на веб-сервере, которые потребуют модульного тестирования. –