Интеграционные Unit-тесты в 1С. Как тесты на обмены улучшили жизнь пользователям, разработчикам и бухгалтерии

Меня зовут Ольга Севастьянова, я ведущий разработчик в компании «Финтех-Решения», тимлид команды ERP. Поделюсь опытом написания интеграционных тестов в 1С и расскажу, как они упростили нашу работу:

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

• Напишем тест, используя инструмент Vanessa-ADD.

• И доработаем правила обмена с помощью методики «разработка через тест».

 

Инструменты для разработки и тестирования

 

 

При решении поставленной задачи мы будем использовать:

• Vanessa ADD – набор инструментов для проверки качества решений на платформе 1С.

• Расширения с тестами – здесь можно сделать небольшую отсылку к докладу Юрия Гончарука, он подробно рассказал, как писать такие расширения с тестами. 

 

 

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

• плагины Vanessa ADD – «УтвержденияBDD», «БазовыеУтверждения», «СериализаторXML» и т.д.,

• любые типовые алгоритмы обмена: загрузка-выгрузка XML, загрузка-выгрузка JSON, получение ссылки, проверка регистрации на узле обмена и т.д.

 

Постановка задачи

 

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

• ТБ – самописная торговая база.

• База №2 – УПП.

• База № 3 – Ортикон.

• №4, №5, №6 – другие базы.

Правила обмена между базами имеют следующую специфику:

• Между основными базами настроен обмен через универсальный формат КД 3 – это значит, что у каждой из этих баз есть ОбщийПакетXDTO и общий модуль МенеджерОбменаЧерезУниверсальныйФормат. Обмены в обе стороны, поэтому, меняя правила у одной базы и что-то напутав, обмен может упасть совершенно с другой стороны. За этим у нас следят тесты.

• Также есть и другие обмены, которые написаны по старинке на КД 2 – там все правила хранятся в макете XML.

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

 

Мне поступила задача – изменить правила обмена для документа «Платежное поручение исходящее» так, чтобы при миграции документа в базу-приемник:

• с 1 сентября;

• для типа операции «Прочее списание»;

• всегда подставлялась статья движения денежных средств – Статья № 1;

• а назначение платежа всегда собиралось по формуле: ХозяйственнаяОперация + Контрагент + СуммаДокумента + Валюта + (НДС).

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

Расскажу мой порядок действий при доработке правил обмена с помощью методики «разработка через тест»:

• Первый шаг – подготовка вводных данных:

  • Выгружаем документ «Платежное поручение исходящее» из базы-источника по существующим правилам (формат xml).

  • В расширении «Тесты» базы ERP добавляем новый макет для загрузки XML документа «СписаниеБезналичныхДенежныхСредств».

• Второй шаг – написание теста:

  • Добавляем новый тест в набор тестов.

  • Пишем часть теста (только загрузку документа) чтобы зафиксировать текущее поведение до изменений. Если теста на текущее поведение нет, то пишем его тоже. В моем примере тест уже есть и мы создадим только новый.

  • В режиме 1С:Предприятие запускаем тест, используя инструмент Vanessa-ADD.

  • Проверяем, что документ загрузился.

  • Меняем руками то, что просят доработать в ТЗ – Статью ДДС и Назначение платежа.

  • Комментируем строку загрузки документа. Перезапускаем и фиксируем в тесте нужные нам значения (для удобства пользуемся отладкой).

• Третий шаг – доработка правила обмена:

  • Доработка кода в модуле МенеджерОбменаЧерезУниверсальныйФормат.

  • Делаем нужные настройки в режиме предприятия.

  • Прогоняем – тест зеленый. Кто молодец? Я молодец!

• Четвертый шаг – дополнение теста поставляемыми данными:

  • Используя инструмент Vanessa-ADD, выгружаем нужные нам поставляемые данные – настройки, которые могут понадобиться при работе.

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

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

Все эти шаги я сейчас покажу подробно, с картинками.

 

Первый шаг – подготовка вводных данных

 

Расскажу о том, как я готовлю вводные данные.

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

В данном случае я создаю документ типа «Прочее списание» и заполняю все, что нужно – указываю произвольное назначение платежа и первую попавшуюся статью ДДС.

 

 

Далее с помощью стандартной обработки «ВыгрузкаЗагрузкаEnterpriseData», встроенной в конфигурацию, выбираю созданный документ и выгружаю его в текстовый документ формата XML.

 

 

Потом иду в тестовое расширение ERP, создаю в нем текстовый макет для нужного мне объекта метаданных – в данном случае, для документа «Списание безналичных денежных средств». И в созданный макет помещаю XML-документ, который я только что выгрузила из базы источника.

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

 

Второй шаг – написание теста

 

 

Перехожу к созданию теста.

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

Сами наборы хранятся в общих модулях с префиксом подсистемы: «ЦФГ_Тест_Казначейство», «ЦФГ_Тест_Обмены», «ЦФГ_Тест_Продажи» и прочее. Там же для каждого теста из набора хранятся ссылки, где его искать.

 

 

А сами тесты, где прописаны проверки ожиданий, размещаются в общих модулях, названных по конкретному объекту метаданных – в нашем случае, в модуле «ЦФГ_Тест_Документ_СписаниеБезналичныхДенежныхСредств». В нем я и создаю процедуру с конкретной проверкой.

Обратите внимание, что здесь используются наши помощники:

• с помощью помощника ЦФГ_Тест_ПомощникТестированияКлиентСервер я описываю, что ожидаю инициацию контекста ядра;

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

• последним шагом получаю ссылку этого документа – ее UUID заранее известен.

На этом все. Останавливаюсь и иду в режим 1С:Предприятия.

 

В режиме 1С:Предприятия открываю Vanessa-ADD и загружаю тесты из расширения.

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

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

 

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

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

 

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

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

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

 

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

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

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

 

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

 

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

В принципе, тест готов.

 

 

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

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

 

Третий шаг – доработка правил обмена

 

Перехожу к доработке правил обмена в универсальном формате КД 3.1.

Я понимаю, что мне нужно в общем модуле МенеджерОбменаЧерезУниверсальныйФормат поменять логику процедуры ОтложеннаяОбработка_ДокументыДвиженияБезналичныхДС.

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

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

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

В итоге я решила сделать свою процедуру ЗаполнениеНазначениеПлатежаИСтатьиДДС() и добавить ее с условием по документу «СписаниеБезналичныхДенежныхСредств» в эту отложенную обработку.

 

 

Вот так выглядит пример решения:

• Обрабатывается только документ «СписаниеБезналичныхДенежныхСредств».

• Учитывается условие по типу документа «ПрочееСписание»

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

 

Возвращаюсь в режим 1С:Предприятие и заполняю эти настройки, что с 1 сентября у меня теперь должна применяться новая настройка, а в ней – такая-то статья и фиксированное назначение платежа.

 

 

После того как я обновила правила и внесла настройки, прогоняю все тесты.

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

 

Четвертый шаг – дополнение теста поставляемыми данными

 

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

Для подготовки этих макетов я использую Vanessa-ADD – там в выпадающем меню «Внешние инструменты» есть инструмент «Генератор макетов данных».

 

И по очереди, в два этапа, выгружаю в JSON нужные мне объекты – справочник и регистр сведений.

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

Полученные JSON-файлы кладу в расширение с тестами – помещаю их в макеты поставляемых данных в привязке к конкретным объектам конфигурации: справочнику и регистру сведений.

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

 

Выводы

 

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

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

2. Мне не понадобилось настраивать обмены между двумя, а то и тремя базами.

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

4. Наличие соседних тестов помогает безопасно менять любые правила или код. Тем более, что модуль МенеджерОбменаЧерезУниверсальныйФормат очень большой, и его постоянно дорабатывают разные программисты – каждый со своими задачами, объекты которых пересекаются. Иногда приходится вносить изменения в большие процедуры с десятками условий, где Sonar уже требует рефакторинга. При наличии тестов можно спокойно наводить порядок, писать красивый читаемый код, разбивать все по модулям. А когда этих тестов нет, естественно, начинаешь бояться, поскольку не знаешь верхнеуровневую логику и как на нее повлияет твоя маленькая задача.

 

Сейчас у нас уже более 700 тестов – и это только в расширении ERP.

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

 

Тесты на выгрузку и проверку пакета XDTO мы пишем не только в ERP, но и в соседних базах, которые обмениваются с ERP – в ТБ и Ортикон. Если где-то выполняется выгрузка и этот процесс связан с ERP, мы фиксируем в тестах ожидаемое нами поведение.

 

Также пишем тесты на регистрацию, потому что важно понимать – что должно регистрироваться, а что не должно.

 

Минусы разработки через тестирование:

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

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

 

Плюсов гораздо больше:

• Защита от регрессионных ошибок. У нас в команде ERP 50 разработчиков, плюс из других команд 15 человек участвуют в задачах по обменам с ERP. Мы можем вообще не знать задачи друг друга, но благодаря тестам мы можем контролировать логику интеграции. И если кто-то уронит соседний тест, то как-то договариваемся. Если требуется с какой-то даты что-то поменять, сохранив при этом существующее поведение системы, то, естественно, покрываем тестом то, что нам требуется, и пишем тест на новое поведение.

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

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

• Упрощение сопровождения и развития.

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

• Тесты в расширении, а не в обработках. Это действительно удобно.

• По итогу уменьшаются (или вообще исчезает) количество задач на доработку или исправления ошибок по правилам обмена. Если два года назад пользователи содрогались: «Опять что-то пошло в релиз, обмены падают!», то сейчас они даже не замечают, что у нас активно идет разработка правил обмена и мы ежедневно отправляем изменения в релиз. Если что-то и падает, то только там, где еще нет теста – и после исправления мы сразу его добавляем, чтобы ошибка не повторилась.

• И само расширение с тестами – это прекрасная демобаза для всех. Новый сотрудник подключает пустую базу к хранилищу, загружает из Git постоянное и тестовое расширение, импортирует поставляемые данные и прогоняет все тесты. В результате получается полностью упакованная демобаза с организациями, учетной политикой, всеми нужными справочниками и документами, полностью соответствующая реальным процессам компании. И новый человек может в своей локальной базе вести разработку и опираться на наши примеры. Это очень большой плюс. Мы этим пользуемся и всем рекомендуем.

 

Рекомендации к просмотру

 

Мы бы не смогли писать тесты и делить все это на модули, если бы не соблюдали стандарты при разработке. Об этом можно посмотреть доклады Артема Кузнецова:

• https://www.youtube.com/watch?v=oGEu44LolFA (текстовая версия).

• https://www.youtube.com/watch?v=EsdniggnUJQ (текстовая версия).

А о том, как начать разрабатывать тесты через расширение, можно посмотреть доклад Юрия Гончарука:

• https://www.youtube.com/watch?v=8_EQYDAAXgU

Посмотрите и начинайте писать тесты.

 

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

 

Как разработчикам, которые привыкли тестировать на пользователях и работать по принципу «тяп-ляп и в продакшен», привить культуру тестов?

Хотелось бы сказать, что добровольно-принудительно, но нет. У нас это внедрялось так:

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

• Спустя какое-то время мы уже говорили: «Хорошо, мы задачу принимаем, но за тобой техдолг, сделай тест», чтобы он хотя бы научился это делать. Потому что вначале есть барьер, что с этими поставляемыми данными придется долго возиться. Но когда это делаешь постоянно, то получается накидать тест быстро, как на рефлексе, а разработку потом – тем более.

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

С заказчиками не воевали из-за того, что рабочее время тратится на написание тестов?

Воевали, но у нас же большие объемы, и если происходит любая поломка обмена, то идет накопление данных, и потом только к вечеру система приходит в норму. Сами же заказчики приходили к нам и спрашивали: «Что здесь можно сделать?», и мы им отвечали: «А вот были бы тесты, этого бы не было». Они в определенный момент нам поверили, и сами начали закладывать время, чтобы разработчик помимо разработки делал еще и тест.

Ваш сквозной пример тестирует загрузку данных из одного и того же макета? Вы говорите: «Я шаг за шагом проверяю, пока мой тест не позеленел».

Да, мы используем в этом тесте именно эту одну XML

Как вы тогда тестируете выгрузку?

Я рассказывала, что мы пишем тесты на выгрузку и проверку пакета XDTO на стороне ТБ и Ортикона.

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

Если вы храните данные XDTO в макетах, кто у вас следит за актуальностью этих макетов?

Разработчики и следят. Здесь может быть две ситуации.

• Если старое поведение все еще нужно для какого-то другого условия, оставляем существующую выгрузку и пишем другой тест.

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

Допустим, у нас есть документ «Поступление товаров и услуг». Один разработчик реализует часть логики, зависящую от того, что контрагент – розничный покупатель, другой работает по другому условию. Как в одном макете проверить правила загрузки и поведение этого документа для разных случаев?

Это оформляется как разные тесты с разными макетами, потому что, например, при поступлении товаров от физлица в пакете XDTO будет одно значение свойства, а от юрлица – другое.

Как разработчик должен понять, в какой макет он должен внести изменения? Если уже 30 макетов у одного объекта метаданных, как разобраться, где ему что-то брать?

Мы даем тестам осмысленные названия, отражающие их суть.

• Например, если первый разработчик сделал тест на загрузку физлица, он так и называет его – «ЗагрузкаДляФизлица».

• А следующий реализует функциональность для юридического лица – видит, что существующий тест при его условиях падает, понимает, что там другая ситуация, создает новый тест и называет его соответствующим образом («ЗагрузкаДляЮрлица»)

Кто следит за неактуальностью теста?

У нас пока неактуальных тестов особо нет, мы их, наоборот, только наращиваем.

Если тест регулярно падает и мешает сборке, мы разбираемся, нужен он вообще или нет. Либо дорабатываем, либо отключаем. У нас правило: кто первый столкнулся с проблемой – тот и исправляет.

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

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

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

Вы упомянули, что покрываете тестами и обмены на КД 2.0. А как? Там же сложнее.

Да, там сложнее, потому что помимо данных в XML-выгрузке формата КД 2 содержатся еще и правила. И тестировать их нужно в другой базе. Из-за этого полностью все покрыть не получается. Но мы фиксируем хотя бы результат – например, выгрузили документ или справочник из ДО в XML по правилам КД2, и фиксируем, как должен выглядеть результат его загрузки. Таким образом мы покрываем примерно 50% сценариев (в том числе, регистрацию и отсутствие ошибок при загрузке). Но специфичные условия в обработчиках другой базы пока не тестируем, хотя планируем.

Если для объекта ранее тестов не было, пишете сразу для всех сценариев или только под задачу?

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

Если тест из техдолга нужен другому разработчику, как поступаете?

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

Дорабатывали ли вы стандартные обработки Vanessa-ADD для тестирования правил обмена? Хватало ли стандартных ассертов или потребовалась дополнительная логика?

Нам хватило стандартной функциональности. Единственное, что мы сделали – это небольшие «помощники» в виде оберток над стандартными ассертами Vanessa-ADD. Вы могли видеть их на первых слайдах. Они работают с теми же объектами и командами, просто убирают лишний «словесный мусор» и делают код чище.

Например, есть обертка для проверки, что объект зарегистрирован в обмене. Это упрощает написание тестов, позволяет стандартизировать их поведение и легко заменять вызовы в большом пуле тестов.

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

 

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

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