Зачем программисту автоматизированное тестирование?¶

Программисты находят значительно более эффективной практику написания кода без ошибок, нежели спуск времени на тестирование и рутину с этим связанную. Однако, внедрение автоматизированного тестирования в свою работу – это один из качественных рывков вперед в развитии своих способностей как программиста. Это не научно доказанный факт, но практика показывает, что класс программиста выше, если произведенный им код, он же кодом и проверяет (не обязательно TDD).

Почему в Тестере, все сценарии в виде программного кода?¶

В основе любого сценария лежит алгоритм. Программный код, в совокупности задач по выражению, манипуляции и эволюции логики, является одним из наиболее эффективных способов производства алгоритмов. Создание сценариев в интерфейсном корсете, имеет свои плюсы, но при росте функциональности, это часто приводит к созданию большого количества свойств, соглашений, а структура хранения информации слабо подвержена оперативному рефакторингу, поиску и работе с версиями при групповой разработке тестов. Итоговое время на изучение особенностей, или их отсутствие в связи с ограничениями визуальной модели, может превзойти время изучения десятка методов-оберток Тестера.

А можно не кодировать вручную, а записывать сценарий?¶

Да. В Тестере реализовано несколько механизмов формирования сценария:

Вариант 1: Пишется код вручную.¶

Плюсы:

• Возможность формировать реальные сценарии
• Сценарии получаются краткими (страница кода сценария будет равносильна трем-четырем страницам преобразованного журнала действий пользователя)

Минусы:

• Нужно полностью понимать как работает прикладная модель тестируемого приложения
• Нужно знать язык 1С на базовом уровне

Вариант 2: Сценарий пишется по действиям пользователя (см. на панели микрофон).¶

Плюсы:

• Быстро можно получить тест

Минусы:

• Не всегда тест будет воспроизводим (особенности платформы)
• Тесты очень многословные, содержат много служебной информации и невыразительны
• Реальные тесты очень сложно

Вариант 3: Использование мастера (см. на панели подбор действия).¶

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

Плюсы:

• Быстрое создание шагов
• Интерактивность

Минусы:

• Нужно понимать как работает прикладная модель тестируемого приложения

Общая рекомендация: если вы программист, пишите сценарии кодом.

Почему в Тестере нет средств загрузки начальных данных из макета или файла?¶

Одной из фундаментальных задач при разработке Тестера было желание создать систему, при которой промежуток времени, между написанием кода и его тестом, был бы минимальным. Данная цель была достигнута; следствием стало накопление большого числа тестов: сотни, а для некоторых проектов, тысячи. Такая ситуация предъявляет особые требования к содержанию, прогону и анализу результатов тестирования, с которой мы в свое время успешно не справились.

С ростом количества сценариев, у нас началась фатальная деградация процесса в виде большого числа ложных падений с общим синдромом: устаревание, сложность анализа и потеря понимания тестовых данных разработчиками. Нам понадобилось много времени в виде попыток реализации механизмов представления тестовых данных, начиная с xml, заканчивая табличным документом с хранением непустых значений, цветами областей, умными расшифровками и мини языком с вычисляемыми выражениями, чтобы наконец понять: тестовые данные требуют алгоритма их формирования, рефакторинга и отладки, что попадает под определение “программный код”.

Программный код воплотил собой отсутствие в тестере каких-либо механизмов выгрузки/загрузки данных. Подробнее о реализации подхода читайте в документации Данные для тестирования.

Как организовать специальный порядок выполнения тестов?¶

Желательно этого не делать; правильным решением является несвязность и независимость сценариев от очередности запуска.

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

Такой подход неизбежно приведет к следующим проблемам:

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

Чтобы тесты были независимы, и при этом не приходилось каждый раз повторять похожий код сценария, используйте специальные тест-методы. Это сценарии со специальным признаком, которые потом могут быть вызваны как функции, с передачей в них необходимых параметров. Эти тесты не должны ничего проверять, они должны просто выполняться. Подробней см. в документации Данные для тестирования.