Введение
Разберемся немного в терминологии:
Функциональное (E2E) тестирование - проверка, что сценарии работы пользователя выполняются. Другими словами прогоны тестовых пользовательский сценариев. Поддерживается фреймворками "Сценарное тестирование", "Vanessa-ADD", "Vanessa-Automation", "Тестер" и др. Большинство из этих фреймворков специально созданы для написания функциональных/сценарных тестов.
Unit-тестирование (модульное тестирование) - проверка на корректность отдельные единицы работы исходного кода программы. Минимальными единицами работы для нас являются процедуры и функции.
Получилось так, что наибольшую популярность среди программистов 1С получило функциональное тестирование. Такой вывод можно сделать по обилию публикаций и дискуссий на профессиональных конференциях.
Основной целью такого тестирования при его внедрении в первую очередь является уменьшение ошибок, в том числе организация регрессионного тестирования (англ. regression testing, собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода).
Функциональное тестирование требует подготовки - создание эталонных баз / шаблонов данных, проработки сценариев использования и их написания. Т.е. это больше история про процесс разработки, а не непосредственное написание кода, ответственность за поддержку лежит на команде.
Unit-тесты в противовес функциональным тестам пишется разработчиком в помощь себе. Они позволяют быстро прогнать все возможные варианты входных данных для написанного участка кода, облегчают рефакторинг.
Для Unit-тестов есть один специализированный фреймворк - xUnitFor1C (возможно я не прав, напишите, пожалуйста, в комментариях, если это не так). Его функционал плавно перекочевал в Vanessa-ADD. Также модульные тесты можно запускать и на фреймворках, предназначенных для функционального тестирования. Существуют плагин для EDT для написания unit-тестов с использованием фреймворка Vanessa-Automation (https://github.com/DoublesunRUS/ru.capralow.dt.unit.launcher).
Unit-тестирование и функциональное тестирование не исключают, а дополняют друг друга.
Функциональный тест vs Unit-тест
Попробуем сравнить разные виды тестирования.
Категории сравнения:
Скорость - время выполнения теста
Область действия - что тест проверяет
Сложность написания - объем необходимых знаний
Сложность запуска - насколько сложная инфраструктура нужна для запуска теста, насколько сложно обеспечить повторение однотипных тестов
Изменение трудозатрат на написание тестов с ростом количества тестов - как меняются количество времени, необходимое для написания тестов с ростом количества тестов и накоплением инструментария.
| Критерий | Функциональный тест | Unit-тест |
| Скорость | Медленный | Быстрый |
| Область действия | Сценарий пользователя | Процедура/Функция |
| Сложность написания | Средне | Средне |
| Сложность запуска | Средне | Легко |
| Трудозатраты на написание | Большие | Маленькие |
| Изменение трудозатрат на написание тестов с ростом количества тестов | Уменьшаются | Остаются неизменными |
Скорость
Область действия
Тестовое покрытие функционального теста намного выше. Он проверяет сценарий пользователя, а следовательно и все процедуры/функции, вызываемые во время выполнения.
Unit-тест - обычно проверяет одну функцию или набор связанных процедур.
Сложность написания
C одной стороны Unit-тест писать достаточно легко за счет того, что его область действия очень маленькая. С другой не на всякую функцию unit-тест можно написать, функция должна быть "пригодна" для тестирования (об этом чуть дальше).
Функциональный тест можно записать "накликивая действия" в пользовательском интерфейсе. Большинство фреймворков позволяют преобразовать запись действий пользователя в сценарий, готовый к воспроизведению. К сожалению просто накликанные сценарии сложно поддерживать, приходится оптимизировать сгенерированный код. Да и забота о неизменности данных для тестов становится проблемой: не забывать удалять тестовые данные, делать так, чтобы данные для тестов не пересекались между собой непростая задача.
Сложность запуска
Unit-тест запускается одной кнопкой. Пишем код, запускаем тест.
Для функционального теста необходимо запуск как минимум несколько клиентов: менеджера тестирования и клиента тестирования. Иногда бывают проблемы с портами, по которым тест-менеджер общается с тест-клиентом или подключение тест-менеджер не сразу подключается к тест-клиенту.
Трудозатраты на написание
Первоначальные трудозатраты на написание функциональных тестов довольно большие - необходимо накопить библиотеку "шагов" (подсценариев), которые позволят в дальнейшем быстро писать более высокоуровневые сценарии.
Если пользовательский сценарий большой, то и данных в нем используется много, нужно быть готовым описывать их создание =)
Unit-тест тестирует небольшую функцию, обычно для тестирования функции объем данных намного меньше, чем для пользовательского сценария. Поэтому процесс описания алгоритма их создания займет немного времени.
Если вам нужен большой набор данных для Unit-теста, то скорее всего вы сделали что-то не так =)
Изменение трудозатрат на написание тестов с ростом количества тестов
Для функциональных тестов со временем копится подсценарии и новые тесты становится писать легче.
Для Unit-тестов фреймворк ADD/xUnit предоставляет богатый инструментарий и придумать того, что еще нет, довольно-таки сложно.
На что стоит писать Unit-тесты и что это дает
Удобно писать
- Расчетные механизмы
- Механизмы интеграции
- Любые API
Unit-тесты облегчают воспроизведение граничных случаев для отдельных функций и предоставляют возможность быстро протестировать поведение повторно.
Необходимость в таком тестировании чаще всего встречается в расчетных механизмах, при интеграциях со внешними сервисами, когда нужно протестировать большое количество вариантов входных данных.
Неудобно писать
- Отчеты
- Интерфейсы
Для теста отчета нужно много тестовых данных, в алгоритме их создания можно допустить много ошибок, да и легче это результат проверять функциональным тестом. Чтобы действительно хотелось тестировать локально - это формирование сложных ресурсов с большим количеством "ВычислитьВыражение" на разных уровнях группировок. Но пока для этого нет удобных инструментов =)
Интерфейсы нужно проверять с помощью функциональных тестов, будет быстрее и понятнее. Хотя на часть процедур в формах так и просится написать unit-тест, но необходимо потом аккуратно удалить, то что было создано. Не все инструменты позволяют это легко сделать.
Бессмысленно писать
- Обработки проведения документов
- Обработки проверки заполнения
- Печатные формы
- Отчеты
В этом классе задач огромное количество времени тратится на описание алгоритма формирования данных и конечный результат будет больше зависеть не от проверяемого кода, а ошибок, допущенных при создании тестовых данных. Писать Unit-тест, проверяющий алгоритм создание данных, дело крайне неблагодарное.
Вместо итога
Я попытался обобщить свой опыт написания Unit-тестов. Если у кого-то был другой опыт, было бы здорово, если бы вы рассказали о нём в комментариях =)
В этом посте было мало практический примеров. Этот недостаток постараюсь исправить вот тут: //infostart.ru/public/1085875/
