Как создать тест в 1С: практическое руководство

Тестирование в 1С — это способ проверить, что доработка конфигурации не сломала существующий функционал. Каждый раз, когда вы меняете запрос, модуль проведения документа или печатную форму, ручная проверка всех сценариев занимает часы, а вероятность пропустить ошибку остаётся высокой. Автоматический тест воспроизводит сценарий за секунды и сразу показывает, где поведение программы изменилось.

В экосистеме 1С существует несколько подходов к тестированию: встроенный механизм управляемого тестирования (TestClient/TestManager), фреймворк Vanessa Automation для сценарных тестов на языке Gherkin, инструменты модульного тестирования вроде xUnitFor1C и YAxUnit, а также простые обработки-проверки, которые пишутся прямо во встроенном языке. Выбор зависит от задачи: проверить бизнес-логику удобнее модульным тестом, а пользовательский сценарий — через TestClient или Vanessa.

Материал ориентирован на разработчика или внедренца, который раньше не писал тесты для 1С. Мы разберём, как выбрать подход, создать первый тест, проверить результат и избежать типичных ошибок, которые делают тесты хрупкими и бесполезными.

Какой вид теста выбрать под свою задачу

Прежде чем писать код, определите, что именно нужно проверить. От этого зависит инструмент. Модульный тест проверяет отдельную функцию или процедуру: например, расчёт скидки или формирование номера документа. Сценарный тест воспроизводит действия пользователя целиком: создать заказ, провести, сформировать печатную форму, сверить сумму. Интеграционный тест проверяет обмен данными между системами — обычно это уже зона нагрузочных и регрессионных проверок.

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

Подготовка тестовой базы и окружения

Тесты никогда не запускают в рабочей базе. Создайте копию информационной базы или разверните пустую базу с актуальной конфигурацией. Причина проста: тест создаёт и проводит документы, изменяет справочники, а при ошибке может оставить «мусорные» данные, которые попадут в отчёты и обороты.

Для механизма TestClient дополнительно нужно разрешить тестирование. В конфигураторе откройте свойства пользователя (Администрирование → Пользователи) и установите флажок «Защита от опасных действий» отключённой, а в параметрах запуска клиентского приложения укажите ключ /TESTCLIENT для тестируемого сеанса и /TESTMANAGER для сеанса-менеджера. В файловой базе оба сеанса можно запустить на одном компьютере.

Полезно сразу договориться о принципе изоляции данных: каждый тест создаёт себе уникальные тестовые объекты (контрагента с префиксом «ТЕСТ», отдельную номенклатуру) и при возможности удаляет их после завершения. Если тесты опираются на уже существующие в базе элементы, они сломаются при первом же переносе на другую базу.

Создание простого теста во внешней обработке

Самый быстрый способ получить работающий тест — внешняя обработка с процедурой проверки. Создайте новую внешнюю обработку (Файл → Новый → Внешняя обработка), откройте модуль объекта и опишите серверную процедуру, которая выполняет сценарий и сравнивает результат с ожиданием.

Логика теста всегда строится по шаблону «подготовка — действие — проверка». Сначала создаются данные, затем выполняется тестируемая операция, в конце результат сравнивается с эталоном. Если значения не совпали, тест должен вызвать исключение с понятным сообщением — это и есть сигнал о падении.

&НаСервере
Процедура Тест_ПроведениеРеализации() Экспорт
    // Подготовка
    Док = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
    Док.Дата = ТекущаяДатаСеанса();
    Док.ЗаполнитьТестовымиДанными();
    // Действие
    Док.Записать(РежимЗаписиДокумента.Проведение);
    // Проверка
    Если Не Док.Проведен Тогда
        ВызватьИсключение "Документ не проведён";
    КонецЕсли;
КонецПроцедуры

Запускается такой тест открытием обработки в режиме предприятия и вызовом процедуры — например, через кнопку на форме обработки. Для регулярного использования добавьте вывод таблицы результатов: имя теста, статус «успех/ошибка», текст исключения. Уже на десятке тестов без такой таблицы разбираться в результатах станет неудобно.

Тест через TestClient: воспроизведение действий пользователя

Когда нужно проверить не код, а поведение интерфейса — доступность кнопок, заполнение формы, открытие отчёта, — используется управляемое тестирование. Сеанс-менеджер (запущенный с ключом /TESTMANAGER) программно управляет сеансом-клиентом (/TESTCLIENT): открывает формы, нажимает кнопки, вводит значения в поля.

Тест для TestClient пишется на встроенном языке в модуле обработки, запущенной в сеансе-менеджере. Объекты TestClientForm, TestClientFormElement позволяют найти элемент формы по имени и выполнить действие. Важно опираться на имена элементов, а не на заголовки: заголовки меняются при переводе интерфейса или переименовании, и тест сломается.

1. 1
   Создайте копию базы и включите разрешение тестирования в свойствах пользователя
2. 2
   Запустите один сеанс с ключом /TESTMANAGER, второй — с /TESTCLIENT
3. 3
   В сеансе-менеджере откройте обработку с кодом теста
4. 4
   Установите соединение с клиентом тестирования через объект TestClient
5. 5
   Запишите сценарий: открытие формы, заполнение полей, нажатие кнопок по именам элементов
6. 6
   Добавьте проверку результата: значение поля, наличие записи, текст сообщения
7. 7
   Запустите тест и убедитесь, что он проходит, затем намеренно измените ожидание и проверьте, что тест падает

Главное ограничение TestClient — скорость и хрупкость. Каждое действие идёт через интерфейс, поэтому сценарий из пятидесяти шагов выполняется минуты, а изменение формы разработчиком ломает тест. Поэтому TestClient применяют точечно: для критичных пользовательских сценариев, а не для проверки расчётов.

Сценарные тесты в Vanessa Automation

Vanessa Automation — открытый фреймворк, в котором тесты описываются текстовыми сценариями на языке Gherkin: «Дано», «Когда», «Тогда». Такой сценарий читается аналитиком или тестировщиком без знания встроенного языка, а фреймворк превращает шаги в действия TestClient.

Типичный сценарий выглядит как последовательность: «Дано я открываю основную форму списка документа РеализацияТоваровУслуг», «Когда я нажимаю на кнопку с именем ФормаСоздать», «Тогда открылось окно Реализация». Библиотека стандартных шагов покрывает большинство действий с формами, поэтому первые сценарии часто пишутся вообще без кода.

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

Проверка результата и признаки качественного теста

Написанный тест нужно проверить сам. Первый контроль — тест проходит на корректной конфигурации. Второй — тест падает, если намеренно сломать проверяемую логику (например, изменить формулу расчёта). Тест, который проходит в обоих случаях, ничего не проверяет.

Сообщение об ошибке — часть теста. Формулировка «Итоговая сумма документа 1500 не совпадает с ожидаемой 1200» позволяет понять проблему без запуска отладчика, а «Ошибка проверки» заставляет заново воспроизводить ситуацию вручную.

Типичные ошибки при создании тестов

Отдельная ошибка — попытка покрыть тестами всё сразу. Начинайте с критичных мест: проведение ключевых документов, расчёт налогов и цен, обмены. Пять стабильных тестов на критичную логику полезнее пятидесяти хрупких на второстепенные формы.

Как встроить тесты в ежедневную работу

Ценность теста определяется регулярностью запуска. Минимальный уровень — запуск пакета тестов перед каждым обновлением рабочей базы: сначала обновляется копия, на ней прогоняются тесты, и только при успехе обновление переносится в продуктив. Это резко снижает число аварийных ситуаций после релизов.

Следующий шаг — автоматический запуск по расписанию или при изменении хранилища конфигурации. Для этого обработки с тестами должны уметь запускаться пакетно, без интерактивных действий, и возвращать код результата. Vanessa Automation и YAxUnit такой режим поддерживают из коробки, для самописных обработок его придётся предусмотреть самостоятельно.

Частые вопросы о создании тестов в 1С