YAxUnit: Новые возможности для эффективного тестирования в 1С

Меня зовут Алексей Корякин. Я ведущий разработчик компании BIA Technologies и по совместительству автор YAxUnit.

Хочу рассказать о том, какие возможности появились в YAxUnit за прошедший год – как они увеличивают эффективность тестирования и сокращают время на внедрение модульных и интеграционных тестов в компании.

Улучшение документации YAxUnit

Начнем с основы любого качественного продукта – с документации.

• Документация по YAxUnit достаточно хорошо проработана и постоянно поддерживается в актуальном состоянии – в ней отражаются любые значимые изменения, благодаря чему ей всегда можно доверять.

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

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

В результате документация стала заметно лучше:

• Детально проработаны сложные описания – для принципов работы различных структурных механизмов добавлены блок-схемы и диаграммы последовательности, а также даны подробные разъяснения, чтобы люди могли лучше понимать работу движка и совершать при написании тестов меньше ошибок.

• Добавлено большое количество разнообразных примеров.

• Описаны типичные ошибки и способы их избегать. Понимая, что большинство разработчиков читают документацию «по диагонали», мы дополнительно выделили важные моменты, чтобы акцентировать на них внимание.

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

• А еще появился новый достаточно объемный раздел с рекомендациями. В нем собраны общие советы по тестированию и тест-дизайну: как писать качественные тесты, как их правильно именовать, какую структуру выбирать и как поддерживать тесты в долгосрочной перспективе. Все рекомендации основаны на лучших практиках индустрии и адаптированы под специфику 1С. Также есть рекомендации по работе с самим движком – его паттерны и антипаттерны: например, статья о том, как работать с тестовыми данными. Об этом и так уже много где говорится, но теперь это все зафиксировано в одном месте.

Почему мы вообще уделяем документации так много внимания?

• Потому что тестирование в 1С – задача сама по себе непростая. Мы автоматизируем сложные бизнес-процессы, а значит, даже модульные и интеграционные тесты неизбежно получаются сложными. И в такой ситуации важно не усложнять жизнь разработчику еще больше.

• Наша цель – дать максимально полную, удобную и актуальную информацию, сделать и сам инструмент, и документацию простыми и понятными. Чтобы разработчик мог сосредоточиться на главном: на решении своих задач, качестве кода и качестве тестов.

Долгий запуск тестов: решение в YAxUnit

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

И все это время разработчик просто ждет. Написали тест, запустили – ждем. Платформа загрузилась, тест быстро отработал, получили отчет, внесли правки – снова запуск и снова ожидание.

В эти моменты мы обычно отвлекаемся: проверяем телефон, разговариваем с коллегами. В итоге проходит полчаса, а что именно мы делали – уже не всегда понятно. Теряется контекст, приходится заново вспоминать, на чем мы остановились, а это снова время. В результате мы не просто теряем время – мы начинаем выбиваться из сроков.

Чтобы уложиться в дедлайны, разработчики либо полностью перестают писать тесты, либо ограничиваются формальными проверками «для галочки». А переключение между ожиданием и работой демотивирует. Все это напрямую отражается на качестве тестов и на качестве продукта в целом.

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

Сценарий разработки при этом остается прежним: вы просто пишете тесты в общем модуле и запускаете их – либо все вместе, либо по отдельности прямо из кода по иконке в левом поле редактора.

Теперь о том, как это устроено технически.

После того как мы написали тесты и нажали кнопку «Запустить», поднимается 1С:Предприятие, прогоняются тесты, и по результатам прямо в EDT формируется отчет.

При этом сеанс 1С не закрывается – он продолжает ждать команд от EDT. Эти команды доставляются в него через транспорт на базе WebSocket, поддержка которого появилась в платформе 8.3.27. Понятно, что не у всех используется последняя версия 1С – у многих платформа старее. Для таких случаев была разработана внешняя компонента, реализующая поддержку WebSocket. Огромное спасибо Дмитрию Любаневичу, который оперативно откликнулся, реализовал компоненту и помог с устранением проблем. Это позволило поддержать взаимодействие через WebSocket для всех платформ, начиная с версии 8.3.10.

Если по отчету видно, что сам тест работает неправильно, мы можем внести в него исправления и опять нажать кнопку «Запустить». Причем здесь уже не нужно стартовать 1С заново – запущенный сеанс просто получает из EDT команду запуска обновленного тестового модуля с различными параметрами. После из текста тестового модуля формируется внешняя обработка и запускается на стороне 1С, а результат возвращается по вебсокету в EDT.

Все это упрощает запуск тестов и позволяет быстро получать их результаты.

Но есть некоторый ряд ограничений.

• Через WebSocket передается только тестовый модуль – изменения в других модулях не учитываются.

• Если вы написали тест и нашли ошибку в коде конфигурации, вам все-таки потребуется перезапуск после ее исправления.

• Внутри тестового модуля нельзя поставить точки останова, потому что его код запускается как внешняя обработка, а не общий модуль. Зато можно поставить точки останова в проверяемом коде, но нужно помнить, что при его изменении вам все-таки придется обновиться.

В результате внедрения для тестовых методов транспорта через WebSocket мы получили следующие преимущества:

• Моментальный запуск тестов.

• Время на разработку и отладку наших тестов существенно сокращается.

• Мы не теряем контекст – а значит, можем быстрее реализовать решение самой задачи.

Правда есть пара минусов, о которых мы уже поговорили:

• Этот подход применим только для тестов.

• И мы теряем возможность использовать в тесте точки останова.

Сложности разработки тестов в конфигураторе: решение – редактор тестов YAxUnit в предприятии

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

• В конфигураторе мы не можем дополнить тестовыми методами контекстную подсказку.

• В частности, конфигуратор не подсказывает по текучим выражениям (Fluent), которые являются фишкой YAxUnit и помогают писать более лаконичные тесты. Отсутствие подсказки сильно усложняет работу, потому что разработчику, чтобы вспомнить доступные варианты, приходится либо постоянно обращаться к документации, либо «проваливаться» в код движка, тратя на это дополнительное время.

• В конфигураторе нет команд запуска для теста.

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

Все это сильно снижает эффективность и вообще затрудняет написание тестов в конфигураторе. На мой взгляд, в таком режиме тестированием занимаются только энтузиасты.

Решение этой проблемы простое: не пишите тесты в конфигураторе. Пишите их в предприятии.

Для решения этой проблемы мы разработали специальный редактор тестов, который запускается из режима 1С:Предприятие как обработка с полем HTML-документа, куда внедрен Monaco Editor – облегченная веб-версия Visual Studio Code, знакомого многим разработчикам.

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

В первую очередь, в него встроены полноценные контекстные подсказки по API YAxUnit:

• Есть информация по методам.

• Есть поддержка текучих выражений.

• Есть подсказки по платформе – методы, типы, конструкторы, перегрузки.

• Разве что, к сожалению, пока нет подсказки по конфигурации.

Также в редакторе тестов YAxUnit добавлены шаблоны кода – как по платформе, так и по движку. На слайде вы можете увидеть шаблон для конструктора объекта – это позволяет писать код быстрее.

И, конечно, предусмотрен удобный запуск тестов.

• Над каждым тестовым методом отображается команда «Run test», которая позволяет запустить тест.

• После выполнения теста слева в панели выводится иконка со статусом теста (успешный он или проваленный) и при наведении на нее отображается некоторая сводная информация.

На слайде видно, что серверный метод Вычитание() при использовании параметров «5, 2, 2» упал – возникла ошибка в утверждении проверки равенства Равно(). Проверка не отработала.

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

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

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

Немного технических подробностей о том, как это все устроено.

• Как я уже говорил, в качестве основы используется Monaco Editor, который предоставляет базовую функциональность по редактированию текста и ряд продвинутых возможностей. Мне особенно нравится режим мультикурсора – если вы еще не пробовали, рекомендую.

• Для анализа кода используется генерация AST-дерева – это некоторое иерархическое объектное представление кода. Именно это представление по факту является базой для всей основной функциональности редактора.

• Анализ кода происходит в режиме реального времени. Причем стандартно каждый раз при добавлении или изменении символов в код AST-дерево полностью перестраивается. Но на больших модулях, особенно, если там используется сложная логика, это может вызывать проблемы – редактор начинает тормозить и расходовать слишком много ресурсов. Для решения этой проблемы был реализован инкрементальный разбор – когда у нас анализируется только часть текста и обновляется только часть дерева. Такой подход позволяет комфортно работать даже с большими тестовыми модулями размером до десятков тысяч строк.

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

• Плюс в редактор встроено описание YAxUnit и его API, а также описание платформы.

Все это вместе позволяет выдавать хорошие подсказки по коду.

Например, на слайде мы видим код с тремя выражениями:

• В первой строке создается таблица значений и присваивается в переменную «Таблица»

• Во второй строке в эту таблицу добавляется новая колонка и результат записывается в переменную. При этом редактор знает, что метод «Добавить» у таблицы возвращает результат с типом «КолонкаТаблицыЗначений».

• И в третьей строке, когда редактор видит нашу переменную, он уже знает, что у нее тип – «КолонкаТаблицыЗначений». И знает, какие у колонки могут быть свойства и методы – таким образом может дать релевантные подсказки.

В итоге мы получили удобный функциональный редактор, который позволяет:

• Быстро писать тесты для YAxUnit.

• Быстро их запускать.

• Получать быстрый фидбэк и быстрые отчеты.

• И сократить время на разработку и тестирование.

Подготовка тестовых данных

Следующая важная тема – это тестовые данные.

• Одна из фундаментальных проблем в 1С заключается в том, что бизнес-логика практически всегда тесно сплетена с данными.

• Более того, даже сам код хранится в базе данных.

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

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

С решением этой проблемы нам помогло сообщество. Было создано несколько инструментов, которые позволяют работать с тестовыми данными:

• редактор макетов с тестовыми данными;

• генератор кода;

• помощник создания тестовых данных.

Кратко расскажу о каждом из них.

Первый инструмент – редактор макетов. Он позволяет преобразовать данные:

• Из формата табличного документа в таблицу Markdown.

• И обратно – из Markdown в табличный документ,

Это очень простой и универсальный механизм, который помогает в множестве сценариев.

Например, нам для теста нужна корректно заполненная номенклатура. Мы находим нужный элемент номенклатуры в справочнике через фильтр в динамическом списке и выводим данные в табличный документ через пункт меню «Вывести в список».

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

В итоге, используя API YAxUnit, мы можем загрузить это все обратно в справочник и в дальнейшем использовать – например, при создании документа «Приход товаров».

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

Для более сложных сценариев есть два дополнительных инструмента:

• помощник создания тестовых данных;

• и генератор кода.

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

Эти помощники дают нам следующие возможности:

• Генерацию скриптов для создания объектов на основании существующих данных.

• Поддержку различных видов объектов – можно создавать документы, справочники, бизнес-процессы и так далее.

• Формирование движений документов – для проверки либо для создания необходимого тестового контекста.

• Все сценарии формируются с использованием конструкций YAxUnit.

• Также есть возможность генерировать макеты.

Благодаря этим инструментам:

• Снимается проблема «чистого листа», когда нужно протестировать новую функцию, разработчик часто не знает, какие данные подготовить, и как их корректно заполнить.

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

• Это позволяет нам готовить реалистичные наборы данных для сложных сценариев.

• В частности, мы можем воспроизводить баги – нашли проблемный документ, сериализовали, добавили в тест, проверили воспроизведение. Если не воспроизводится – сериализовали дополнительные связанные объекты, дополнили контекст и добиваемся, чтобы тест воспроизводил баг.

На сквозном примере покажу, как эти помощники помогают нам писать тесты.

Для тестирования возьмем базу с конфигурацией «Управление парком аттракционов», где нам необходимо проверить, как в документе «Реализация билетов» формируются его проводки.

Мы открываем редактор и создаем нужные методы.

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

Заходим в проводки и из меню вызываем команду «Вывести список».

Дальше закидываем это все дело в редактор макета и преобразуем в формат маркдауна.

Результат переносим в тест – добавляем документ «Поступление товаров» и загружаем в его движения данные из макета. Входящие остатки готовы.

Далее подготавливаем сам документ реализации.

Открываем генератор кода, добавляем туда документ и нажимаем кнопку «Сформировать код».

Получившийся результат переносим в тест и немного дорабатываем, заменяя заполнение некритичных для нас реквизитов на методы ФикцияРеквизитов() и ФикцияОбязательныхПолей().

Чтобы новый документ корректно сопоставился с остатками, используем номенклатуру из кэша значений. Записываем в переменную «Товары» результаты кэша и используем их при заполнении документа.

После проверки, что все работает, нам остается только сформировать ожидания – добавить утверждения для проверки движений.

И все – тест готов. Весь процесс занимает порядка пяти минут, а на выходе мы получаем полноценный тест.

Искусственный интеллект

ИИ потихоньку входит в нашу работу и даже личную жизнь. С его помощью уже сейчас можно без проблем формировать MVP для различных проектов – например, он хорошо справляется с UI, в него все эти знания уже заложены.

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

В частности, если не уходить далеко от темы тестирования, в других языках программирования давно существуют системы сборки, с которыми нейронки уже умеют эффективно взаимодействовать: pytest, Maven, Gradle и другие.

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

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

Чтобы подобный подход стал возможен и для тестов в 1С, был разработан MCP:Test runner.

Думаю, многие уже знакомы с понятием MCP – по сути, это протокол, расширяющий возможности искусственного интеллекта. MCP:Test runner добавляет для нейронок следующие возможности:

• Позволяет им запускать тест.

• Но прежде, чем запустить тесты, их сначала необходимо собрать – собрать конфигурацию, обновить информационную базу, загрузить туда расширение с тестами и дополнительные расширения. Все это на себя берет MCP:Test runner.

• Он позволяет работать с исходниками в формате конфигуратора и в формате EDT.

• Чтобы все это работало быстро мы выполнили ряд оптимизаций – в частности, загружаются только те проекты (конфигурации или расширения), которые были изменены. А для загрузки и конвертации исходников используется 1C:EDT CLI, запущенная в интерактивном режиме, что позволяет сократить время конвертации, не поднимая каждый раз EDT.

Что это нам в итоге дает?

• В первую очередь, это запуск тестов – проверка, что наше решение работает так, как нам необходимо.

• При сборке и выполнении теста формируется логика, которая позволяет проверить, что проект корректно собирается, и все UUID-ы правильные.

• Плюс в YAxUnit есть механизм, который помогает перехватывать ошибки компиляции – не выбрасывать большое красное исключение, а логировать их. Это позволяет проверить, что наш код компилируется, что он исполняемый – как тестовый код, так и проверяемый.

Покажу, как это все у нас устроено.

Нам нужна IDE с поддержкой ИИ (я использую Cursor), куда можно подключить этот MCP.

В этой IDE мы открываем проект, где необходимо проверить работу тестового модуля, открываем окно чата и пишем: «Запусти такие-то тесты».

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

• Мы видим, сколько у нас тестов всего, сколько из них выполнены успешно, а сколько – провалились.

• Видим время выполнения каждого теста.

• И видим ошибки, которые повлияли на эти тесты. Нейронка их проанализировала, поняла, в чем проблема, и вывела рекомендации.

При этом нейросеть может не только сформировать рекомендации, но и исправить.

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

Также дополнительно можно попросить ее проанализировать сам тестовый модуль – какие в нем есть проблемы. Здесь она тоже выявила ряд критических ошибок:

• Есть странная проверка, что результат равен результату.

• И есть неполное покрытие тестом.

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

Все это автоматически исправляется и доводится до зеленого результата в тесте.

В основном нейронка все делает хорошо, но это не значит, что ее не нужно контролировать.

На примере видно, что вместо того, чтобы исправить существующий код, она предложила более простое и надежное решение – удалить падающий тест.

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

Что мы получаем в итоге:

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

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

Пишите тесты, используйте YAxUnit.

Вопросы и ответы

Могут ли нейронки сами писать тесты для YAxUnit? Или для этого обязательно нужны MCP?

Чтобы научить нейронку писать тесты для YAxUnit, есть три возможности:

• Можно в качестве MCP использовать context7.com – это MCP, который предоставляет информацию о различных библиотеках и работает онлайн, через интернет. Там добавлен YAxUnit, его можно подключить.

• Если вы используете Cursor или что-то подобное, вы можете просто подключить документацию по написанию тестов в проект.

• Либо можно написать для нейросети правила и добавить их в контекст – например, скормить ей файл с описанием.

На простые методы модульные тесты они пишут без проблем, интеграционные (для проверки связи между компонентами) – тоже смогут. Но если у вас большие сложные сценарии, им будет нужна помощь. Если им эту помощь дать – без проблем.

MCP работает с исходниками в формате EDT или в формате конфигуратора? И где производится сама настройка MCP – где мы указываем базу и т.д.?

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

Планируется ли развитие дымовых тестов? Сейчас мы используем для этого Vanessa ADD, но, может, уже стоит все тестирование перенести в YAxUnit?

YAxUnit – действительно удобный инструмент для написания дымовых тестов, но сейчас механизм дымового тестирования реализован там как плагин, и нет уверенности, что его нужно тащить прямо в движок. Мне кажется, это усложнит и размоет назначение инструмента. Vanessa ADD в плане дымовых тестов пока что действительно умеет больше.

Заинтересовал редактор тестов. Он входит в состав расширения для YAxUnit? Можно ли забрать из репозитория на GitHub шаблоны для Monaco Editor?

Можно забрать не только шаблоны, но и весь редактор целиком, если нужно.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.