Разработка конфигураций в платформе 1С:Предприятие требует строгого подхода к качеству кода, особенно когда речь идет о сложных бизнес-процессах. Ручное тестирование функционала занимает колоссальное количество времени и часто подвержено человеческому фактору.
Автоматизация проверок через встроенные инструменты платформы позволяет выявлять регрессии и ошибки еще на этапе написания кода. Это существенно ускоряет релизный цикл и повышает стабильность работающих систем.
Подготовка к автоматизированному тестированию
Прежде чем погрузиться в написание сценариев, необходимо убедиться, что ваша конфигурация готова к работе с механизмом тестирования. В современных версиях платформы эта функция является стандартной, но требует явного включения в свойствах конфигурации.
Вам потребуется доступ к режиму Конфигуратора с правами администратора или разработчика. Откройте свойства вашей конфигурации и перейдите на вкладку "Дополнительно". Именно здесь находится ключевой переключатель, активирующий подсистему тестов.
Обратите внимание, что после включения опции Поддержка тестов, в дереве метаданных появится новая ветка. Она будет называться "Сценарии" и станет основным местом хранения ваших проверочных сценариев.
Перед включением тестирования обязательно создайте резервную копию базы данных, так как изменение состава метаданных может затронуть существующие данные в некоторых случаях.
⚠️ Внимание: Включение поддержки тестов увеличивает время обновления конфигурации базы данных. На больших проектах этот процесс может занять несколько минут.
Создание первого сценария тестирования
Создание нового теста начинается с добавления объекта метаданных типа "Сценарий". Вы можете создать его как в корневой папке, так и в отдельной подпапке для лучшей структуризации кода. Назовите сценарий осмысленно, например, ТестированиеПроведенияДокумента.
Откройте редактор сценария. Здесь вы увидите поле для ввода кода на встроенном языке 1С. Структура теста обычно состоит из этапов, которые выполняются последовательно. Каждый этап описывает конкретное действие системы или проверку условия.
Для начала работы вам необходимо открыть тестируемую форму. Это делается с помощью метода ОткрытьФорму объекта ИнтерфейсТестирования. После этого вы получаете доступ к элементам управления формы через объект-обертку.
☑️ Алгоритм написания сценария
Код сценария должен быть написан в модуле объекта. Пример простейшей проверки может выглядеть так:
Процедура Тест()
Интерфейс = ИнтерфейсТестирования.ПолучитьИнтерфейс();
Интерфейс.ОткрытьФорму("Справочник.Номенклатура");
Форма = Интерфейс.АктивнаяФорма;
Форма.КомандаСоздать.ВыполнитьКоманду();
КонецПроцедуры
Вам может потребоваться использовать метод Ждать или проверки на появление элементов, чтобы синхронизировать выполнение скрипта с отрисовкой интерфейса.
Использование библиотеки xUnit для 1С
Хотя встроенные сценарии удобны для проверки интерфейсов, для модульного тестирования логики лучше подходит фреймворк xUnit. Это сторонняя, но стандартизированная библиотека, которая позволяет писать тесты в стиле unit-тестирования, привычном для разработчиков других языков.
Для подключения xUnit вам нужно скачать репозиторий библиотеки и добавить её в вашу конфигурацию как внешнюю обработку или включить в состав метаданных. Основные классы, которые вам понадобятся, находятся в пространстве имен XUnit.
Создание теста в xUnit начинается с объявления класса, помеченного аннотацией &Тест. Внутри класса методы, которые являются самими тестами, также помечаются этой аннотацией. Это позволяет тест-раннеру автоматически находить и запускать их.
Пример структуры теста с использованием утверждений (assertions):
&Тест
Процедура ПроверкаРасчетаСуммы()
Сумма = МодульРасчетов.РассчитатьСумму(100, 20);
Утверждать.Равно(Сумма, 120, "Сумма рассчитана неверно");
КонецПроцедуры
Использование xUnit дает возможность параметризации тестов, что позволяет запускать один и тот же сценарий с разными наборами входных данных. Это критически важно для проверки граничных значений и сложных алгоритмов.
⚠️ Внимание: Библиотека xUnit требует наличия определенных общих модулей в конфигурации. Убедитесь, что все зависимости подключены корректно перед запуском тестов.
Работа с данными в тестах
Одной из главных проблем при тестировании является чистота данных. Тесты не должны зависеть от информации, оставшейся в базе от предыдущих запусков или ручной работы пользователей. Для решения этой проблемы используются временные базы данных или механизмы транзакций.
При запуске тестов в режиме предприятия часто создается временная информационная база. В неё загружается только необходимая часть метаданных и начальные данные. Это обеспечивает изоляцию тестового окружения.
Если вы работаете в основной базе, обязательно очищайте созданные в ходе теста объекты. Используйте конструкцию Попытка..Исключение для гарантии удаления данных даже в случае падения теста.
| Тип данных | Стратегия очистки | Риск загрязнения |
|---|---|---|
| Справочники | Пометка на удаление | Высокий |
| Документы | Отмена проведения + Удаление | Средний |
| Регистры | Сдвиг периода или очистка | Критический |
| Временные таблицы | Автоматическое удаление | Низкий |
Для работы с регистрами накопления или сведений часто используются специальные методы библиотеки тестирования, которые позволяют делать снимки состояния регистров до и после теста. Сравнение снимков показывает, какие именно движения были сделаны системой.
Почему нельзя тестировать на рабочей базе?
Тестирование на рабочей базе может привести к порче реальных данных, блокировке пользователей и неверным отчетам. Всегда используйте выделенное окружение.
Запуск и анализ результатов
После написания кода наступает этап верификации. Запустить тесты можно непосредственно из конфигуратора через меню Администрирование -> Тестирование -> Запустить тесты. Также возможен запуск из режима Предприятия через специальные обработки-раннеры.
Результаты выполнения отображаются в специальном окне. Успешные тесты помечаются зеленым цветом, а упавшие — красным. Для каждого неудачного теста система предоставляет протокол с описанием ошибки и стеком вызовов.
Анализ логов — ключевой этап отладки. Если тест падает на шаге проверки утверждения, внимательно изучите ожидаемое и фактическое значения. Часто ошибка кроется не в логике теста, а в изменении поведения тестируемого кода.
Регулярный запуск набора регрессионных тестов (Smoke Test) перед каждым коммитом кода позволяет предотвратить поломку основного функционала системы.
В корпоративной среде запуск тестов часто интегрируют в процесс непрерывной интеграции (CI/CD). Для этого используются консольные утилиты запуска 1С, которые позволяют выполнять тесты в автоматическом режиме без участия пользователя.
Типичные ошибки и решение проблем
Новички часто сталкиваются с проблемой "мигающих" тестов, которые то проходят, то нет. Это обычно связано с неправильной синхронизацией действий с интерфейсом. Элемент формы может еще не успеть отрисоваться, когда скрипт пытается к нему обратиться.
Другая распространенная ошибка — нарушение принципа независимости тестов. Когда один тест полагается на данные, созданные другим тестом, порядок их выполнения становится критичным. Это делает набор тестов хрупким и сложным в поддержке.
Используйте методы ЖдатьУсловие или циклы с проверкой наличия элемента перед взаимодействием с ним. Это сделает ваши сценарии более стабильными и устойчивыми к задержкам в работе интерфейса.
Добавляйте комментарии к сложным участкам кода тестов. Через полгода вы можете забыть, почему именно так была реализована проверка, и комментарии сэкономят время на разбор.
⚠️ Внимание: Интерфейс методов тестирования может меняться в новых версиях платформы 1С. Всегда сверяйте актуальность синтаксиса с документацией к вашей конкретной версии платформы.
Часто задаваемые вопросы (FAQ)
Можно ли запускать тесты на сервере 1С без графического интерфейса?
Да, это возможно. Для этого используются специальные режимы запуска в тонком клиенте в режиме предприятия или через консольные утилиты 1cv8.exe с ключами автоматизации. Однако тесты, завязанные на GUI, могут требовать эмуляции ввода или использования headless-режимов.
Как тестировать фоновые задания и регламентные операции?
Для тестирования фоновых заданий необходимо использовать механизмы ожидания завершения фоновой обработки. В xUnit есть специальные методы для работы с фоновыми задачами, позволяющие дождаться их выполнения перед проверкой результата.
Нужно ли писать тесты для простых справочников?
Обычно нет. Тесты имеют смысл там, где есть сложная бизнес-логика, расчеты или взаимодействия между объектами. Простые CRUD-операции для справочников лучше проверять вручную или покрывать минимальным набором сценариев.
Что делать, если тест падает только на одном компьютере?
Это может указывать на зависимость от локальных настроек, прав доступа пользователя или версии платформы. Проверьте идентичность версий 1С, права пользователя в базе и наличие внешних обработок, которые могут влиять на поведение.
Как ускорить выполнение большого набора тестов?
Оптимизируйте создание тестовых данных, используя минимально необходимый набор реквизитов. Разбивайте большие тесты на мелкие независимые единицы. Используйте параллельный запуск тестов, если ваша инфраструктура и версия платформы это поддерживают.