вторник, 12 марта 2013 г.

Автотесты на автотесты ?

Зачастую процесс автоматизации тестирования со временем обрастает набором своих собственных вспомогательных библиотек, надстроек, эмуляторов, заглушек и т.д., которые используются в конечных автотестах. Эти "библиотеки" могут решать совершенно разные задачи , но все их объединяет одна банальная вещь - это код, а код очень часто содержит баги.

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

Попробуем разобраться, почему так происходит...

  1. многим тестировщикам просто в голову не приходит , что их код это тоже код и он тоже может содержать ошибки
  2. кто по вдумчивее скажет: тестерский код часто меняется, не решает бизнес-задач пользователя, денег не несет и потому риски багов  в нем ничтожны - да, это аргумент
  3. кто-то понимает , что "по-хорошему надо бы обложить тестами", но не делает этого ввиду нехватки времени, желания , а порой отсутствия такой активности как таковой в группе тестирования, отсуствия такого прецедента....
Первый пункт обсуждать, думаю, не имеет смысла - это вопрос опыта, осознанности..

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

Да, отсутствие юнит-тестов на тестовые библиотеки и  как следствие баги в тестовом коде не несут с собой очевидных финансовых , репутационных рисков для конечного потребителя софта. Но ложные провалы тестов из-за поломок в тестовом софте - это оверхед, нервы и "лишние движения".

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

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

4 комментария:

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

    ОтветитьУдалить
  2. Первое и самое главное - сложного тестового кода быть не должно. Иначе это какое-то "we need go deeper". Иногда случаются исключений, тогда да - TDD, юнит тесты и прочая прочая.

    ОтветитьУдалить
    Ответы
    1. Согласен, код тестов должен быть максимально прост и читаем.
      Но я говорил не о коде автотестов, а о служебном коде , который постепенно кристаллизуется во всяческие вспомогательные либы или утилиты.
      Пример из жизни - программный "эмулятор" NAS для тестирования ААА-сервера. Там, к сожалению, код ну никак не может быть совсем уж простым (

      Удалить
    2. Да обычных хелперов, выдранных из девелоперского кода, или используемых в тестах вызовах API уже достаточно. Их нужно тестами накрыть в любом случае.

      Удалить