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

К примеру есть три документа: заказ поставщику, приобретение товаров и услуг и приходный ордер. Документы вводятся в программе последовательно. Я получаю некие данные из документа "Заказ поставщику". А как мне дальше с ними работать?

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

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

таким образом - если у вас есть ошибка формы элемента справочника товаров, то первый тест у вас упадет, а второй - отработает корректно

вот и вся цель

Идея понятна. Непонятно пока что как это реализовать на практике) Спасибо за пояснение.

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

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

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

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

Так получается?

Одно неловкое движение в ЗУП подсистемы и у вас два одинаковых основания увольнения и база больше не обновляется... С приколами приёма я так и не разобрался, но документ встал в режим проводится, но не открывается. В общем не зашли у меня макеты в зуп.

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

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

тесы для мобильного приложения на 8.3.19 никто не пытался использовать?

пытались, может на следующей недели пошлю пул. Ну и тут буду рассказывать про это https://mobile.1c.ru/sreda/

Отлично. Спасибо, послушаем.

Добрый вечер, коллеги!)  Столкнулся с проблемой, не могу найти её решение.
Установил через opm install -all все пакеты, через батник вызываю runner, а система мне выдаёт, что не знает такой команды. Что в таком случае делать? Пытался ванессу в переменную среды закинуть, но результата нет

При простом запуске команды runner то же самое