От Phase Switcher до KOT for 1C 3.0: как из маленькой утилиты выросла среда разработки автотестов 1С

История расширения для VS Code: от ускорения сборки тестов до полноценной работы со сценариями СППР и Vanessa Automation.

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

В какой-то момент я написал небольшую утилиту на Python, которая автоматизировала этот процесс. Тогда я ещё не планировал создавать среду разработки автотестов — хотелось просто избавиться от одной из повседневных неудобных операций.

Позже эта утилита стала основой расширения для Visual Studio Code. А спустя примерно полтора года после появления его первых версий, 30 октября 2026 года, вышла версия KOT for 1C 3.0.0 — расширения, в котором можно создавать и редактировать сценарии, работать с библиотеками шагов, управлять информационными базами, запускать тесты и выполнять отдельные шаги непосредственно из редактора.

Хотя проект начинался с автоматизации сборки YAML-сценариев СППР, сегодня он предназначен не только для них. Если вы пишете обычные .feature непосредственно для Vanessa Automation, без СППР и её компилятора, KOT тоже поддерживает такой рабочий процесс. Для сценариев доступны IntelliSense, библиотека шагов, навигация, диагностика, запись действий и управление выполнением через Vanessa.

Рабочая область KOT 3.0: редактор сценария, Менеджер тестов, информационные базы и Свойства теста. IntelliSense предлагает элементы активной формы 1С.

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

Хочу рассказать, как всё начиналось, какие решения определили развитие KOT и что в итоге получилось.

Началось всё с YAML и получасовой сборки

Исторически автотесты нашей команды хранились в YAML-файлах. Специальная обработка компилировала их в feature-файлы, которые затем выполнялись через Vanessa Automation.

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

Сами сценарии мы редактировали непосредственно в VS Code или Notepad++. Для создания нового теста обычно находили похожий сценарий, копировали его и изменяли необходимые части.

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

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

Отдельной проблемой оставалась скорость сборки.

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

Возник очевидный вопрос: почему бы это не автоматизировать?

Phase Switcher: первая попытка избавиться от рутины

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

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

Так появился Phase Switcher.

Phase Switcher 6 — одна из ранних версий Python-утилиты. Можно выбрать нужные тесты и вариант продукта, не изменяя test.yaml вручную.

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

На тот момент я не руководил командой и не определял её рабочие процессы. Да и сама разработка Phase Switcher не была рабочей задачей — я занимался ей по собственной инициативе, в свободное от основной работы время.

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

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

Откуда вообще взялся наш формат тестов?

Ещё во времена Phase Switcher мне стало интересно разобраться не только в структуре наших YAML-файлов, но и в происхождении всей системы.

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

Постепенно изучая формат, я пришёл к выводу, что используемые нами сценарии относятся к СППР — системе проектирования прикладных решений.

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

Когда-то один из первых тестировщиков, выстраивавший систему автоматизации практически с нуля, использовал СППР. Однако остальная команда разработки непосредственно с ней не работала. Со временем самой СППР в нашем рабочем процессе уже не было, а специализированные знания о ней постепенно утратились после ухода первоначального специалиста.

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

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

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

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

Первые эксперименты с VS Code

Вообще, мысли о более удобной среде разработки тестов возникали у меня ещё до появления KOT.

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

После Phase Switcher я продолжил экспериментировать с инструментами, которые могли бы упростить написание тестов. Попробовал создать небольшое расширение для VS Code, использовавшее сниппеты и конструкции, напоминающие Emmet.

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

Одна из ранних идей: описывать сценарий короткими конструкциями, которые затем превращаются в YAML с необходимыми метаданными и шагами.

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

Никакого полноценного IntelliSense или интеграции с Phase Switcher там не было. Более того, это был совершенно самостоятельный эксперимент, не связанный с Python-утилитой.

Долго он не прожил, но помог немного разобраться в разработке расширений и возможностях VS Code.

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

Если мы всё равно пишем сценарии в VS Code, почему бы не перенести туда Phase Switcher и добавить инструменты, которые упростят редактирование YAML?

Так началась разработка будущего KOT.

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

1C:Drive Test Helper: от переключения тестов к пониманию сценариев

Изначально расширение называлось 1C:Drive Test Helper и создавалось для нашей команды.

Одной из основных задач на старте стал перенос функциональности Phase Switcher с Python на TypeScript и API VS Code.

Одна из ранних версий 1C:Drive Test Helper: Phase Switcher переехал в боковую панель VS Code.

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

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

Больше не нужно копировать технические блоки

В версии 1.2.0 появилось автодополнение шагов Gherkin на основе библиотеки Vanessa Automation, а также подсказки с описаниями шагов. В 1.4.0 логика сборки переехала из нашего скрипта автоматизации непосредственно в расширение.

В 1.5.0 появилось автодополнение вызовов вложенных сценариев с их параметрами, а в 1.6.0 — автоматическое заполнение секций ВложенныеСценарии и ПараметрыСценария.

1C:Drive Test Helper по мере развития: появились сборка тестов из VS Code и команды редактора для создания сценариев, работы с параметрами и вложенными вызовами.

Именно последние функции мне особенно нравились в ранних версиях.

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

Тестировщику больше не приходилось постоянно переключаться между написанием проверки и обслуживанием формата файла.

Постепенно из этих небольших автоматизаций сформировалась основная идея проекта:

Тестировщик должен заниматься логикой проверки, а редактор — помогать поддерживать техническую структуру сценария.

Это не означает, что YAML плох или что СППР устроена неправильно. У любого формата есть определённые требования. Но если часть этих требований редактор способен соблюдать автоматически, зачем постоянно перекладывать эту работу на человека?

Когда идей стало больше, чем времени на их реализацию

Первые версии расширения развивались довольно бурно. Если первоначальный Phase Switcher команда встретила со скепсисом, то переход в VS Code вызвал гораздо больше энтузиазма.

Коллеги стали активно предлагать улучшения и сообщать об ошибках. Кому-то не хватало возможности останавливать сборку, кто-то предлагал доработки IntelliSense, кто-то хотел автоматизировать очередную операцию с YAML.

Отдельной задачей оказалась обратная совместимость.

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

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

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

Почему KOT?

К версии 2.0.0 расширение заметно выросло и уже не ограничивалось первоначальным Phase Switcher. Оно помогало редактировать сценарии, работать с параметрами, находить вложенные вызовы, выполнять компиляцию и автоматизировать множество технических операций.

Название 1C:Drive Test Helper стало слишком узким.

В версии 2.0.0 проект получил новое имя — KOT for 1C, или Keep On Testing. Панель Phase Switcher при этом превратилась в Test Manager.

Почему именно кот? Всё довольно просто: я люблю кошек, а корпоративным маскотом нашей команды тоже является кот. Захотелось как-то отразить это в проекте.

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

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

При этом я не собирался заменять Vanessa Automation или СППР собственным тестовым фреймворком. Наоборот, хотелось использовать возможности существующей экосистемы и объединить работу с ними в редакторе.

От написания теста к его выполнению

Постепенно KOT начал выходить за пределы редактирования сценариев.

Если тест уже можно написать и собрать из VS Code, логично было бы видеть там и результат его выполнения.

В версии 2.3.1 появилась live-подсветка шагов в feature-файлах во время выполнения через Vanessa Automation. Редактор начал показывать текущий шаг, успешно выполненные строки, ошибки и дополнительную информацию при наведении. Позже появилась возможность отслеживать и внешние прогоны по журналам.

Следующим направлением стала подготовка тестовых окружений.

При автоматизации 1С регулярно приходится создавать информационные базы, восстанавливать DT, обновлять конфигурации, выбирать версию платформы и переключаться между окружениями. Так в версии 2.5.1 появился KOT Infobase Manager.

Примерно тогда же был добавлен KOT Form Explorer — исследователь форм, позволяющий получать сведения об элементах интерфейса 1С непосредственно из VS Code.

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

Для этого мы всё равно обращались к исследователю форм Vanessa Automation. Хотелось объединить и эту часть работы с редактором.

Первые отклики за пределами команды

Со временем расширением начали пользоваться и за пределами нашей QA-команды. Появлялись обращения от сторонних пользователей, которые пытались разобраться, можно ли применить KOT в собственном процессе тестирования.

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

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

Это ещё раз показало, насколько разными могут быть потребности команд, работающих даже с похожими инструментами.

KOT 3.0.0: когда небольшое обновление снова вышло за рамки плана

История версии 3.0.0 в каком-то смысле повторяет историю появления самого KOT.

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

Но постепенно возникла мысль: почему ограничиваться только стандартными шагами Vanessa?

Ведь в проекте существуют пользовательские шаги на встроенном языке 1С (BSL), экспортные сценарии Vanessa, вложенные сценарии и процессы СППР. По сути, всё это — повторно используемые строительные блоки тестов.

Так идея отдельной библиотеки шагов переросла в концепцию общей библиотеки проекта.

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

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

Позже я начал изучать MCP-интерфейс Vanessa Automation и понял, что он хорошо подходит для ещё одной давно существовавшей идеи — управления выполнением тестов непосредственно из редактора.

Здесь стоит отдельно пояснить, что MCP (Model Context Protocol) в данном случае используется как интерфейс взаимодействия с работающим сеансом Vanessa. KOT напрямую обращается к предоставляемым Vanessa инструментам, передаёт команды и получает результаты. Для этого не требуется LLM или какой-либо AI-сервис.

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

30 октября 2026 года вышла версия KOT for 1C 3.0.0.

Ниже покажу несколько примеров того, как теперь работают её основные компоненты.

Начать работу стало проще

Одной из задач версии 3.0 было упростить первое знакомство с KOT. Раньше для настройки расширения требовалось самостоятельно разобраться во множестве параметров VS Code, путях к инструментам и структуре проекта.

Теперь при первом запуске доступен мастер настройки. Он предлагает несколько вариантов: создать новый проект, подключить существующие сценарии СППР или самостоятельные feature Vanessa, а также перенести настройки предыдущих версий KOT. Перед применением можно посмотреть, какие файлы и параметры будут изменены.

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

От текста сценария до выполненного шага

Для примера возьмём небольшой фрагмент из учебного проекта KOT.

Главный сценарий СППР вызывает вложенный сценарий и передаёт ему параметр покупателя:

And I prepare workshop customer
    Customer = [Customer]

Здесь Customer слева от знака равенства — параметр вызываемого сценария, а [Customer] справа — ссылка на параметр текущего сценария, значение которого будет подставлено при компиляции.

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

Теперь подходящий вложенный сценарий можно найти через IntelliSense или Библиотеку, просмотреть его параметры и вставить вызов в редактор. При включённой синхронизации KOT также помогает поддерживать объявления параметров и вложенных сценариев в соответствии с текстом теста.

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

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

And I save "[Customer]" in "WorkshopCustomer" variable

Параметры сценария можно посмотреть и изменить в панели Свойств теста, не разыскивая нужную секцию большого YAML-файла.

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

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

В нашем примере после выполнения шага сохранения появится переменная WorkshopCustomer, значение которой можно посмотреть непосредственно в VS Code.

Аналогичным образом KOT позволяет управлять выполнением самостоятельных feature-файлов Vanessa Automation, не требующих предварительной компиляции СППР. На скриншоте ниже показан такой сценарий из учебной мастерской: выполнение шага и просмотр переменных непосредственно в VS Code.

Выполнение шага и просмотр переменных на примере самостоятельного feature-сценария Vanessa Automation.

На этом возможности управления выполнением не заканчиваются:

• F11 — выполнить отдельный шаг непосредственно из редактора.
• Запуск выделения или с выбранной строки — проверить нужный участок сценария.
• Точки останова — приостановить прогон и затем продолжить выполнение.
• Результаты и переменные — увидеть подтверждённые состояния шагов, значения переменных и доступные подробности ошибок.
• Переход к исходнику — найти соответствующую строку исходного сценария по карте сборки.

Короткая демонстрация выполнения и отладки.

Конечно, здесь есть важные ограничения.

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

Кроме того, возможности управления зависят от версии Vanessa и доступного в ней MCP API.

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

Библиотека: найти шаг, даже если не помнишь его название

В версии 3.0 Библиотека объединяет стандартные шаги Vanessa Automation, пользовательские BSL-шаги, экспортные сценарии Vanessa, а также вложенные и главные сценарии, процессы СППР и самостоятельные feature-файлы.

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

Полноразмерный интерфейс Библиотеки KOT 3.0: категории и источники определений, поиск, просмотр параметров и действия с выбранным сценарием.

При этом Библиотека — не просто отдельный каталог определений. Её данные используются непосредственно в редакторе для IntelliSense, подсказок, диагностики и переходов к определениям.

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

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

Семантический поиск шагов Vanessa: по свободному запросу на русском языке KOT находит подходящие англоязычные определения и показывает их описания.

Сами каталоги Vanessa версионируются отдельно от расширения и могут обновляться независимо от выпуска нового VSIX — пакета расширения VS Code. Это позволяет получать определения шагов для новых версий Vanessa без необходимости выпускать обновление всего KOT.

Для пользовательских BSL-шагов есть дополнительная особенность.

Наличия исходного кода недостаточно для выполнения — необходимо собрать библиотеку в виде внешней обработки 1С (EPF) и подключить её к Vanessa. KOT позволяет создавать и собирать такие библиотеки, а также отслеживает актуальность сборки.

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

Это помогает заранее обнаружить ситуацию, когда редактор уже знает о новом шаге, а работающая Vanessa ещё не может его выполнить.

Разные форматы сценариев — одна рабочая среда

Изначально KOT был ориентирован на YAML-сценарии СППР. В версии 3.0 появилась поддержка нескольких вариантов исходников.

Классический scen.yaml по-прежнему содержит и служебные данные, и текст сценария. Но теперь можно использовать раздельное представление:

scenario/
    scen.feature
    meta.yaml

В scen.feature находится текст шагов, а в meta.yaml — параметры, связи, метаданные и другие служебные сведения СППР.

Редактор, диагностика и Свойства теста работают с ними как с единым сценарием.

Важно, что такой scen.feature остаётся частью СППР. Для полноценного выполнения он по-прежнему требует компиляции.

Отдельно поддерживаются и самостоятельные feature-файлы Vanessa Automation. Их можно создавать, редактировать, организовывать, настраивать и выполнять без компилятора СППР. Поэтому использовать KOT можно и в проектах, где СППР вообще не применяется.

Кроме того, появились инструменты преобразования между YAML и feature + meta, между главными и вложенными сценариями или процессами, а также между вложенными и экспортными сценариями.

Из Свойств теста можно изменить формат исходника или преобразовать сценарий в другой поддерживаемый тип.

При этом не все конструкции разных форматов эквивалентны. Например, некоторые типы параметров СППР нельзя безопасно перенести в экспортный сценарий Vanessa.

Поэтому перед преобразованием KOT проверяет совместимость и останавливает операцию, если невозможно гарантировать корректность результата.

Отдельное внимание пришлось уделить старым проектам.

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

Переход выполняется явно, а автоматическое преобразование YAML при сохранении по умолчанию отключено.

В данном случае сохранение совместимости оказалось важнее стремления автоматически перевести всех пользователей на самый новый формат.

От исследования формы до записи действий

Ещё одна область, которую хотелось объединить с редактором, — работа непосредственно с интерфейсом тестируемого приложения.

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

Для этого предназначен KOT Form Explorer.

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

Исследователь форм показывает элементы интерфейса, их технические имена и доступные действия Vanessa.

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

В версии 3.0 взаимодействие с формами поддерживается в том числе через MCP Vanessa Automation.

Другая возможность — запись действий.

Можно начать запись из VS Code и выполнить необходимые операции в тестовом клиенте — записанные шаги появятся непосредственно в открытом сценарии. Дальше это обычный редактируемый текст: можно изменить параметры, вынести повторяющийся фрагмент во вложенный сценарий или объединить записанные действия с уже существующими проверками.

Запись действий в клиенте тестирования прямо из интерфейса VS Code.

При этом сами механизмы исследования форм и записи действий давно существуют в Vanessa Automation — мы пользовались ими ещё до появления KOT. Идея заключалась не в том, чтобы изобрести их заново, а в том, чтобы сделать доступными непосредственно из VS Code и связать с другими возможностями редактора.

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

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

Информационные базы и тестовые клиенты

В версии 3.0 заметно изменился и KOT Infobase Manager. Теперь он объединяет сохранённые подключения и тестовые клиенты, обнаруженные в работающей Vanessa Automation. Можно видеть несколько клиентов одной информационной базы, различать их по пользователям и параметрам подключения, подключать и отключать клиентов непосредственно из VS Code.

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

Кроме того, из менеджера можно восстанавливать базы из DT-шаблонов и обновлять их из CF-шаблонов. В результате подготовка окружения и работа с тестовыми клиентами становятся ещё одной частью общего процесса, доступного непосредственно из редактора.

Почему этот подход прижился в нашей команде

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

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

При этом KOT уже давно не ограничивается исходным подходом. Мы можем работать со сценариями СППР в разных представлениях, использовать самостоятельные feature Vanessa и преобразовывать поддерживаемые конструкции между форматами.

В версии 3.0 появились и дополнительные возможности для совместной работы. Группы тестов, описания и категории можно хранить вместе с исходниками и передавать через Git, тогда как личные настройки отображения остаются у каждого пользователя. Отдельные профили параметров позволяют работать с несколькими проектами, не смешивая их настройки.

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

Не все эксперименты оказались одинаково полезными

За время разработки KOT появлялись функции, которые выглядели перспективно, но на практике использовались гораздо реже, чем я ожидал.

Например, в версиях 2.6.0 и 2.7.0 появились AI-инструменты: генерация описаний сценариев, анализ изменений конфигурации и ревью тестов.

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

Хотелось автоматически анализировать такие сценарии и формировать описание.

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

В результате существующий AI-функционал KOT практически не используется нашей командой.

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

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

Сложнее всего оказалось не писать код

Если говорить о технических трудностях, самым непростым для меня, наверное, было начало: перенос существующей функциональности на другой язык и освоение API VS Code.

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

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

Гораздо труднее продумать правильное поведение инструмента.

Что должно произойти, если пользователь переключает Git-ветку во время преобразования сценариев? Как открыть свойства теста, не изменив существующий проект? Что показывать, если Vanessa продолжает выполнение, но очередной запрос её состояния завершился ошибкой?

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

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

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

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

Для версии 3.0.0 я также существенно расширил автоматические проверки самого расширения: они охватывают в том числе совместимость со старыми проектами, переключение веток, преобразования форматов и обработку состояний Vanessa.

Конечно, автоматические тесты расширения не заменяют практическую проверку на разных версиях платформы 1С, СППР и Vanessa. Но для дальнейшего развития проекта такая система проверок стала важной основой.

А что дальше?

С выпуском 3.0.0 я всё больше воспринимаю KOT как самостоятельный open-source проект, а не просто набор инструментов для нашей команды.

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

У разных команд свои процессы, наборы инструментов и требования. Кто-то работает преимущественно непосредственно в Vanessa, кто-то активно использует СППР, а кто-то строит собственную инфраструктуру автоматизации.

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

Какие возможности действительно помогают? Какие решения неудобны? Что слишком сильно привязано к нашему первоначальному процессу? Какие инструменты и форматы стоило бы поддерживать в дальнейшем?

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

Исходный код KOT открыт, проект распространяется по лицензии MIT. Поэтому буду рад сообщениям об ошибках, предложениям, обсуждениям и Pull Request.

Как попробовать KOT for 1C

Для первого знакомства не обязательно сразу настраивать полноценное окружение 1С.

В версии 3.0 появилась учебная мастерская с примерами сценариев СППР, самостоятельных feature Vanessa, процессов, параметров, экспортных сценариев и пользовательских шагов.

В ней можно попробовать навигацию, IntelliSense, Библиотеку, Свойства теста и другие возможности редактора.

Для выполнения сценариев потребуется соответствующее окружение: совместимая платформа 1С, Vanessa Automation и необходимые компоненты. Редактирование и изучение сценариев доступны и без установленной 1С. Локальная компиляция, подготовка информационных баз и запуск 1С рассчитаны на Windows.

Ссылки на проект:

• KOT for 1C в Visual Studio Marketplace
• GitHub-репозиторий
• Релиз 3.0.0 и история изменений
• Быстрый старт
• Учебная мастерская
• Визуальный обзор возможностей

Вместо заключения

За время существования KOT прошёл путь от небольшой Python-утилиты для выборочной сборки до расширения, объединяющего создание, сопровождение и выполнение тестов. Ни один из этапов этого развития изначально не планировался в таком масштабе — проект рос вместе с потребностями команды и моим собственным пониманием того, как можно улучшить рабочий процесс.

Конечно, KOT пока далёк от идеала. В нём остаются ограничения и решения, которые со временем наверняка придётся пересматривать. Но основная идея практически не изменилась со времён первого Phase Switcher.

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

---

Отдельное спасибо разработчикам СППР, Vanessa Automation и связанных инструментов, а также моим коллегам из команд тестирования и DevOps нашего проекта за идеи, обратную связь и помощь с инфраструктурой.