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