Наверное, почти любой тестер скажет - "Хорошо, когда разработчики пишут unit-тесты на свои библиотеки".. Кто-то при этом дополнит " а если не пишут, то давайте напишем мы..." Для чего? Конечно же для того, чтобы итоговый продукт был более качественным. Это все банально и понятно. Но когда дело касается кода тестерских либ, то тут повсеместно наблюдается весьма странная вещь - код этих библиотек довольно редко обкладывается тестами.
Попробуем разобраться, почему так происходит...
- многим тестировщикам просто в голову не приходит , что их код это тоже код и он тоже может содержать ошибки
- кто по вдумчивее скажет: тестерский код часто меняется, не решает бизнес-задач пользователя, денег не несет и потому риски багов в нем ничтожны - да, это аргумент
- кто-то понимает , что "по-хорошему надо бы обложить тестами", но не делает этого ввиду нехватки времени, желания , а порой отсутствия такой активности как таковой в группе тестирования, отсуствия такого прецедента....
Аргумент номер два весомый, но его вес заметно снижается с увеличением количества тестов, использующих ту или иную тестовую библиотеку, а также с усложнением кода таких библиотек или с увеличением их количества.
Да, отсутствие юнит-тестов на тестовые библиотеки и как следствие баги в тестовом коде не несут с собой очевидных финансовых , репутационных рисков для конечного потребителя софта. Но ложные провалы тестов из-за поломок в тестовом софте - это оверхед, нервы и "лишние движения".
Поэтому , считаю , далеко не лишним будет минимальный набор тестов , который позволит сразу же заметить поломку в той или иной тестовой либе, заглушке, эмуляторе .
Не надо городить тесты на двустрочечные скрипты, не надо гнаться за покрытием самого тестового кода и разворачивать полноценную "непрерывную интеграцию", но на более-менее сложные куски служебного тестового кода желательно тоже иметь некий набор автотестов, которые мейнтейнер может запустить тут же не отходя от кассы , перед коммитом очередного изменения.
Некоторые автоматизированные тесты можно использовать как сценарии приемки, а их отчеты как пользовательскую документацию. Получается, что можно извлечь пользу от тестов для бизнеса, но с этим подходом нужно быть очень осторожным.
ОтветитьУдалитьПервое и самое главное - сложного тестового кода быть не должно. Иначе это какое-то "we need go deeper". Иногда случаются исключений, тогда да - TDD, юнит тесты и прочая прочая.
ОтветитьУдалитьСогласен, код тестов должен быть максимально прост и читаем.
УдалитьНо я говорил не о коде автотестов, а о служебном коде , который постепенно кристаллизуется во всяческие вспомогательные либы или утилиты.
Пример из жизни - программный "эмулятор" NAS для тестирования ААА-сервера. Там, к сожалению, код ну никак не может быть совсем уж простым (
Да обычных хелперов, выдранных из девелоперского кода, или используемых в тестах вызовах API уже достаточно. Их нужно тестами накрыть в любом случае.
Удалить