Автоматизация расчета покрытия кода тестами

Публикация № 1445790 21.05.21

Методология - DevOps - Скрипты автоматизации

На Infostart Meetup, посвященном DevOps-технологиям, с докладом о том, как автоматизировать расчет покрытия кода, выступил программист компании 42Clouds Станислав Косолапов. Станислав рассказал об инструменте собственной разработки для таких задач и показал работу решения на практике.

Я занимаюсь поддержкой и разработкой технологий для облака 42Clouds. У нас развернуты базы на разделителях, мы используем технологии 1С:Фреш, но немного переделываем их по-своему.

Некоторое время назад мы начитались статей, насмотрелись видео на YouTube и начали активно писать тесты – причем, у нас используются не только сценарные, но и самописные, дымовые тесты.

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

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

 

Инструменты, которые отображают покрытие

 

Что такое покрытие кода и как оно вычисляется? Алгоритмов, чтобы его посчитать, много, мы будем использовать самый простой – покрытие строк.

 

 

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

На слайде вы видите простую функцию.

  • Все строки, которые могут быть выполнены во время теста, помечаются как строки к выполнению – туда не входят комментарии, пустые строки, инструкции препроцессора, директивы компиляции (&НаКлиенте &НаСервере).

  • Весь остальной код помечается как код к покрытию.

  • Далее запускаются тесты, и анализируется, какие же строки были выполнены во время тестов.

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

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

Тем не менее, даже в достаточно старых докладах уже встречались варианты, когда покрытие как-то считалось. Но эти механизмы никак не афишировались.

 

 

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

 

 

Кроме SonarQube, покрытие можно считать и через другие инструменты – например, через интересный механизм Report Generator, который просто преобразует файл покрытия в HTML-документ, где можно увидеть:

  • что у нас выполнилось, а что – нет;

  • процент по разным модулям;

  • общий процент по проекту.

 

 

Например, видно, что некоторые HTTP-сервисы не были покрыты тестами. Хорошо было бы написать тесты, которые проверяют именно их.

 

 

Тот же VSCode тоже поддерживает отображение покрытия, для этого есть различные плагины:

  • Coverage-Gutters

  • VSCode LCOV

  • Code Coverage Highlighter

Из всех трех лучше всех работал Coverage-Gutters, он на экране. Отмечает красным, что у нас не выполнилось, зеленым – что выполнилось.

То есть отобразить покрытие мы сможем, осталось его добыть.

 

Анализ файлов замеров производительности

 

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

 

 

Для выгрузки замеров производительности в файлы существует инструмент https://github.com/Stepa86/perf-measurements-to-cover, написанный на OneScript.

Он работает хорошо, но требует выполнения большого количества ручных действий в конфигураторе – нужно подключить предметы отладки (HTTP-сервисы, фоновые задания и т.д.), включить замер, запустить тестирование, затем остановить замер и вручную сохранить его данные в файл .pff.

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

 

 

Далее появились более продвинутые инструменты, использующие HTTP-отладку, которая появилась в платформе 8.3.7:

Эти инструменты:

  • поднимают прокси-сервер, который перехватывает вызовы от платформы к серверу отладки dbgs.exe;

  • ищут в передаваемых данных информацию о замере производительности и пишут ее на диск,

  • а потом эта информация неким конвертером преобразовывается в один из стандартных форматов покрытия.

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

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

Поэтому я решил написать свой инструмент – Coverage41C.

 

Coverage41C

 

 

С инструментом Coverage41C вы можете ознакомиться по адресу https://github.com/proDOOMman/Coverage41C. Он написан на Java, поэтому требует для работы установки JDK 11. В своем составе он использует следующие библиотеки:

  • MDClasses https://github.com/1c-syntax/mdclasses для разбора исходников конфигурации, выгруженной в файлы в формате как EDT, так и конфигуратора.

  • BSL Parser https://github.com/1c-syntax/bsl-parser для анализа исходного кода, вычисления строк покрытия.

  • И некоторые библиотеки, входящие в составе EDT https://edt.1c.ru/. Это самое важное, потому что я обнаружил, что EDT содержит библиотеки, которые позволяют подключаться к серверу отладки dbgs.exe и управлять им – включать замеры, получать данные замеров и их анализировать.

  • И чтобы с моим инструментом было удобнее работать, в него добавлено немного магии.

 

 

По поводу библиотек EDT:

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

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

  • Если же вам не хочется тянуть EDT на сервер тестирования – он слишком тяжел для этого, вы хотите держать EDT установленным у себя или вообще против него – вам нужен только конфигуратор. В этом случае, вы можете скопировать из состава EDT в папку библиотеки com._1c.g5.v8.dt.debug.core_*.jar и com._1c.g5.v8.dt.debug.model_*.jar. И установить путь к этой папке в переменную окружения EDT_LOCATION – в этом случае библиотеки также будут подключены и использованы.

Если EDT не установлена или переменная окружения EDT_LOCATION не настроена – при использовании Coverage41C будут выданы ошибки.

 

HTTP-отладчик платформы 1С

 

 

Все видели вкладку «Отладка» в конфигураторе, где есть возможность выбора протокола отладки – HTTP или TCP.

Большинство знакомых разработчиков на вопрос «Что такое отладка по HTTP?» отвечают «Мы не знаем». Но здесь смысл здесь в том, что для EDT нужен отдельный протокол отладки, плюс TCP-протокол отладки был не очень красивым – даже разработчики об этом писали – поэтому появился сервер отладки dbgs, который работал по протоколу HTTP. У отладчика dbgs есть много интересных фишек – например, можно отлаживать одну информационную базу из другой. Но это сейчас не главное.

Многие разработчики путают отладку HTTP-сервисов с HTTP-отладчиком dbgs. Говорят, что отлаживают HTTP-сервис, поэтому, наверняка, включена HTTP-отладка. Но это не совсем так: отладку по HTTP нужно включать отдельно.

Далее немного терминологии.

  • Сервер отладки – это отдельное приложение dbgs.exe, идет в составе платформы.

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

  • Интерфейсы отладки – то, что управляет сервисом отладки: либо конфигуратор, либо EDT, либо моя утилита Coverage 41C.

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

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

    • И наоборот: если запущен замер покрытия и вы пытаетесь запустить конфигуратор, чтобы в этот момент что-то отладить, конфигуратор скажет, что информационная база уже отлаживается, и ничего не позволит сделать.

 

Включаем HTTP-отладку

 

 

Как же включить HTTP-отладку?

  • Если у вас серверная информационная база – необходимо заглянуть в реестр и к флагу -debug добавить флаг -http. После этого мы перезапускаем агент и HTTP-отладка включается. Не забудьте после этого конфигуратор переключить на режим HTTP-отладки, иначе у вас ничего отлаживаться не будет.

  • Если у вас файловая информационная база. Когда вы хотите отлаживать файловую информационную базу через HTTP в конфигураторе – вы меняете в настройках отладку на HTTP и запускаете приложение. В этот момент конфигуратор сам запускает dbgs.exe и держит его запущенным, пока запущено клиентское приложение.

При запуске Coverage41C мы конфигуратор не используем, поэтому dbgs.exe мы должны запустить вручную – файл dbgs.exe лежит в папке с платформой:

  • в качестве аргумента получает порт, на котором будет запущен (-p 1559).

  • второй вариант запуска – в диапазоне портов в первом свободном порте (-r 1560:1591).

Мы для простоты используем вариант с указанием порта – запускаем dbgs.exe, и он ждет, когда мы подключим клиентское приложение.

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

/debug -http -attach /debuggerURL http://localhost:1550

Чтобы проверить, что сервер отладки действительно запустился – мы адрес отладчика можем открыть в браузере. Он выведет нам, что все работает – it works!

 

Поддерживаемые форматы

 

 

Утилита поддерживает два формата (параметр -f):

  • GenericCoverage – используется для SonarQube

  • Lcov.info – для VSCode, ReportGenerator и т.д., возможности применения такого формата гораздо шире.

Они отличаются: GenericCoverage – xml-формат, Lcov.info – просто текстовый формат.

Тем не менее, SonarQube любим одинэсниками, поэтому по умолчанию покрытие выводится в формате GenericCoverage.

 

Интерфейс командной строки

 

 

Утилита представляет собой консольное приложение. Интерфейс не слишком сложный.

Есть основные команды:

  • start

  • stop

  • chek

  • clean

  • dump

  • stats

  • convert

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

 

 

Основные параметры команды start – имя информационной базы и адрес отладчика. По этим параметрам подключается замер покрытия к серверу отладки.

  • Имя информационной базы (параметр -i)

    • Если у вас серверная информационная база – имя информационной базы такое же, как в кластере.

    • Если у вас файловая информационная база, то имя информационной базы будет DefAlias. Можете почитать на ИТС – это имя по умолчанию для любой файловой базы.

  • Адрес сервера отладки (параметр -u). В зависимости от типа базы может быть либо http://localhost, либо URL-адрес сервера 1С:Предприятия.

  • Путь к файлу с адресом сервера отладки (параметр -u:file). Существует вариант, когда сервер отладки запускается в диапазоне портов. Тогда он может вписать свой адрес в файл, а мы можем вместо прямой передачи адреса сервера отладки передать путь к файлу, в котором уже записан его адрес. Этот вариант больше нужен для другого режима замеров покрытия, о котором я расскажу в конце доклада.

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

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

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

  • Если вы хотите измерить покрытие внешней обработки, то флаг -х и путь к epf-файлу внешней обработки в формате file:// и полный путь к файлу. Если где-то ошибетесь – ваше покрытие будет нулевым, потому что файл не найдется в процессе выполнения.

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

  • Путь к исходникам конфигурации (параметр -s). Папка, куда распакована наша конфигурация, наше расширение или внешняя обработка. Для этого параметра поддерживается как формат EDT, так и формат конфигуратора:

    • В случае формата EDT ничего распаковывать не нужно – у нас уже все есть.

    • В случае формата конфигуратора просто выгружаете ваш проект в файлы.

  • Путь к директории проекта (параметр -P). Это путь, откуда вы запускаете анализ проекта SonarQube, он может отличаться от пути к исходникам конфигурации. Вещь весьма специфическая, не буду на ней останавливаться.

Остальные параметры:

  • Удаление метаданных на поддержке (флаг -r). Если вы дорабатываете типовую конфигурацию, возможно, вам не имеет смысла мерить покрытие кода, который находится на замке. Тогда вы можете передать флаг --removesupport, указать уровень (NOT_EDITABLE – на замке, EDITABLE_SUPPORT_ENABLED – с возможностью изменения), и такие объекты метаданных не будут анализироваться.

  • Флаг --out – путь к выходному файлу с данными покрытия. Это файл GenericCoverage.xml или Lcov.info, куда будет записана информация. Если вы его забудете передать, информация будет выведена в консоль.

  • Флаг --password – поскольку dbgs.exe может быть опубликован где-нибудь в интернете, предполагается, что его нужно защищать паролем. Поэтому если dbgs.exe у вас запущен с паролем, то для подключения к нему вам нужно передать этот самый пароль. Причем пароль вводится в интерактивном режиме – при запуске будет запрос «Введите пароль», и вы должны вбить его ручками.

  • Для того, чтобы передавать пароль в режиме pipeline существует еще один аргумент командной строки -p:env, где указывается переменная окружения, в которой записан пароль.

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

 

 

Примеры использования команды start.

  • Измерение покрытия кода для конфигурации в файловой базе:

Coverage41C start -i DefAlias -u http://127.0.0.1:1550 -s D:\Sources -o genericCoverage.xml

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

Coverage41C start -i IBName -u http://server1c:1550 -s D:\Sources -o genericCoverage.xml -r NOT_EDITABLE

  • Покрытие для кода расширения – добавляется имя расширения:

Coverage41C start -e ExtensionName -i DefAlias -u http://127.0.0.1:1550 -s D:\Sources -o genericCoverage.xml

  • Покрытие для кода внешней обработки.

Coverage41C start -x file://D:/Infostart.epf -s D:\Sources\External.mdo -o genericCoverage.xml

Причем с внешними обработками есть особенность: помните, что в параметр -x передается путь к epf-ке в формате uri, а в параметр -s или -P передается не путь к директории, куда распакованы исходники, а путь к корневой xml-ке или к корневому файлу mdo. Он имеет то же наименование, что и наименование вашей внешней обработки.

 

 

Далее команды stop, dump, clean.

  • Stop – останавливает замеры покрытия кода и записывает файл на диск.

  • Dump пишет текущее состояние на диск.

  • Clean очищает информацию о выполненных строках кода в запущенном экземпляре программы.

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

Также команда stop нужна для пайплайнов или скриптов – если хотите прервать команду start, запущенную в консоли, вручную, просто нажмите Ctrl+C. Тогда будет корректное завершение с записью всей информации на диск.

 

 

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

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

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

У команды convert есть:

  • флаг -с – в него передается файл с сырыми данными покрытия (то, что получилось на выходе после сбора покрытия кода);

  • с помощью флага -r также можно удалять код на поддержке;

  • все остальное – путь к исходникам (флаг -s), путь к проекту (флаг -P) и выходной файл (флаг -o) – про них мы уже говорили.

 

Интеграция с Vanessa-ADD/Vanessa-automation

 

 

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

Если вы используете BDD-тестирование – Vanessa-ADD или Vanessa-automation – вы можете скачать библиотеку шагов, которая находится в дебрях моего репозитория по ссылке https://github.com/proDOOMman/Coverage41C/blob/master/src/test/resources/bdd/features/step_definitions/Coverage41C.epf.

Эту обработку нужно положить в папку step_definitions каталога с вашими фичами или каталога библиотек Vanessa, и после обновления кэша шагов у вас появятся готовые шаги.

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

Например, вы можете прямо из кода Gherkin запускать сервер отладки – для этого есть два шага: «И я запускаю сервер отладки» или «И я запускаю сервер отладки в диапазоне портов». На файловых базах я рекомендую вам использовать второй шаг с указанием, на каких портах вы можете запустить dbgs.

При запуске любого из этих шагов будет запущен dbgs.exe, в котором будет указано: работать столько же, сколько жив менеджер тестирования. Полный адрес сервера отладки (URL с портом) будет записан в настройке запуска клиентов тестирования. В целом, это все, что нам нужно, чтобы в дальнейшем клиент тестирования подключился к этому серверу отладки, и можно было снимать замеры.

Для установки Coverage41C есть три варианта:

  • Либо вы просто скачиваете с GitHub последний релиз и его распаковываете – это обычный zip-архив.

  • Либо используете пакетный менеджер Chocolatey с командой «choco install Coverage41C». Но там, возможно, не всегда будут актуальные версии, потому что модерация на Chocolatey очень длительная.

  • И третий вариант – использовать шаг «И я устанавливаю Coverage41C». В этом случае также с GitHub скачивается последняя версия и устанавливается в каталог проекта.

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

Имя информационной базы также вычисляется автоматически при шаге «И я настраиваю отладку клиента тестирования» или «И я запускаю сервер отладки» – любой из этих шагов автоматически определяет имя текущей информационной базы и автоматически заносит его в настройки Coverage41C.

 

 

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

  • И я запускаю сервер отладки

  • И я устанавливаю Coverage41C;

  • И я устанавливаю путь к проекту для анализа покрытия (или «И я устанавливаю путь к исходникам для анализа покрытия»)

  • И я устанавливаю имя выходного файла анализа покрытия

  • И я запускаю анализ покрытия.

Анализ покрытия завершится автоматически после закрытия менеджера тестирования.

Если вы для запуска тестирования используете тот же Vanessa-runner – он автоматом может закрывать менеджер тестирования. После этого замеры завершаются, сохраняются на диск, и после этого вы можете их использовать.

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

 

Работа Coverage41C в режиме реального времени

 

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

Итак, у меня есть:

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

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

  • и папка, где лежит фича и рядом с ней в подпапке step_definitions находится библиотека шагов Coverage41C.epf.

 

 

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

 

 

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

 

 

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

 

 

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

Исходники с данными покрытия мы можем передать в SonarQube, у меня для этого есть специальный bat-файл, в котором вызывается sonar-scanner.bat с ключами -Dsonar.projectBaseDir и -Dsonar.coverageReportPaths – подробнее о том, как загружать исходники в SonarQube вы можете прочитать в документации.

 

 

Запускаем сканирование проекта и посмотрим на результат. Итак, покрытие 66,7%.

 

 

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

На этом прощаюсь: заходите на GitHub https://github.com/proDOOMman/Coverage41C, оставляйте сообщения об ошибках и пожелания – все учтем. Спасибо за внимание.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "DevOps в 1С: Тестирование и контроль качества решений на 1С". Больше статей можно прочитать здесь.

Приглашаем всех 11-12 ноября принять участие в INFOSTART EVENT 2021 в Москве: //infostart.ru/events/1451228/

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Mikhail-Kobtsev 21.05.21 14:26 Сейчас в теме
Стас, спасибо,
когда руки доберутся до покрытия кода, твоя статья будет первой к прочтению :)
2. ltfriend 773 21.05.21 22:22 Сейчас в теме
Расчет покрытия кода чем? Большими болтами? Только в третьем абзаце узнал (так то догадался из самого заголовка), что речь о покрытии кода тестами. Так может, так и написать в заголовке?!
mikeA; suepifanov; Darklight; t278; +4 3 Ответить
5. mikeA 1 26.05.21 08:38 Сейчас в теме
(2) Пока как правило матом покрываем) Причём свой код в том числе))
starik-2005; +1 Ответить
3. Rustig 1202 22.05.21 23:32 Сейчас в теме
(0) сколько у вас людей занимаются этим? как долго внедряли? какой профит от внедрения?
mikeA; CodeNull; alexeyvs77; bocharovki; +4 Ответить
4. Darklight 27 24.05.21 09:56 Сейчас в теме
Супер статья и разработанное решение. Начало, конечно, понятное только тем "кто в танке", но затем - всё достаточно подробно разжёвывается. Узнал много нового (и не только про покрытие тестами). Но, конечно, вначале надо приобщить себя к тестам.
Нахватает в начале только хотя бы странички текста про то - как вообще происходит покрытие тестами исходного кода - то есть немного про сами тесты - чтобы лучше понять - ради чего это делается и какой в этом профит тем, кто ещё далёк от тестов.

И про DefAlias, мне кажется, нужно было подробнее написать. Ну или хотя бы дать прямую ссылку на ITS

А информация об управлении 1C HTTP отладчиком через EDT библиотеки - вообще бесценна. Вот бы такую же глубокую статью (ДОКЛАД) именно по этой теме (+ про принцип логирования)
starik-2005; alexeyvs77; Rustig; a_a_burlakov; +4 Ответить
6. starik-2005 2397 26.05.21 20:47 Сейчас в теме
(4)
информация об управлении 1C HTTP отладчиком через EDT библиотеки - вообще бесценна
Круть! С другой стороны ежу должно быть понятно, что если в ЕДТ есть замеры производительности, то и код для них там есть в виде модуля - это ж эклипс. /Там вообще много чего должно быть, если поискать...
7. Darklight 27 27.05.21 09:26 Сейчас в теме
(6)
Там вообще много чего должно быть, если поискать

Да, наверняка так есть очень много интересного, но без описания API декомпилировать java-classes и разбираться в них подсилу не многим. Да и Java платформу и библиотеки нужно знать очень хорошо!
Ну, а компания 1С вообще очень негативно относится к реверс-инжинирингу и внедрению в разработанные ей структуры данных и алгоритмов в местах на то не предусмотренные (угрожая нарушением лицензионных соглашений)
Но тема да - очень заманчивая....

У меня уже давно руки чешутся сделать свой отладчик и профайлировщик для 1С Предприятие 8 (ибо типовые не очень устраивают; впрочем они меня не устраивают даже в MS Visual Studio или IntelliJ IDEA - хотя меньше, чем в 1С) - по уже частично разобранному, в данной статье/докладе, механизму получения исполняемых строк кода, можно сделать половину того, что хотелось бы. Остальное наверняка можно тоже - просто нужно глубже поковыряться в API внешнего HTTP-отладчика.
Данная статья вдохнула в меня надежду, что это реально сделать (и не бесконечно-сложно). Вот только я не Java-программист :-(
8. roman72 221 28.05.21 12:53 Сейчас в теме
EDT вроде как в свободном доступе нынче.
По крайней мере, для владельцев любой программы 1С точно.
9. kraynev-navi 526 31.05.21 21:06 Сейчас в теме
Отличный инструмент! Вот жаль только, что релиз не менялся аж с 2020. Но с форка утащил более новый.
10. user1596477 02.07.21 14:38 Сейчас в теме
Стандартный вопрос автору работает ли с обычными формами? Если нет, то планируется ли?
Оставьте свое сообщение

См. также

Практические кейсы и примеры создания сценарных тестов с использованием фреймворка Тестирование 3.0

Сценарное тестирование Бесплатно (free)

Начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков на Infostart Meetup DevOps продемонстрировал коллегам работу фреймворка «Тестирование 3.0», рассказал о процессе совместной разработки тестов и порассуждал о мировых тенденциях в тестировании.

11.06.2021    3641    ivanov660    26    

Мастер-класс: Реализация цикла CI/CD на практическом примере с использованием системы Тестер

CI/CD Git (GitHub, GitLab, BitBucket) Сценарное тестирование v8 Бесплатно (free)

На онлайн-митапе Инфостарта «DevOps в 1С» выступил Дмитрий Решитко – руководитель отдела разработки в компании C.T. Consultants Inc. Дмитрий провел мастер-класс, в котором продемонстрировал, как создавать новую функциональность в конфигурации с одновременным использованием инструмента тестирования и реализовать автоматизированное тестирование конфигурации при помещении кода в репозиторий на GitLab.

31.05.2021    1405    grumagargler    0    

Как быстро развернуть автоматическую линию проверки своего решения на 1С, затратив 8 часов и получив выигрыш в 1 человеко/месяц

DevOps SonarQube BDD/TDD-тестирование, Vanessa Бесплатно (free)

У разработчиков 1С уже есть все инструменты, позволяющие использовать современные инженерные практики в 1С. О том, как за 8 часов внедрить автоматические проверки для решений на 1С, снизить в них количество глупых ошибок, а также высвободить ресурсы на более интеллектуальную работу на INFOSTART MEETUP Ekaterinburg.Online рассказал Артур Аюханов.

05.04.2021    6090    artbear    16    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Тестирование и исправление Сценарное тестирование Бесплатно (free)

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

29.03.2021    1368    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Сценарное тестирование v8 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    808    kirinalex    0    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование BDD/TDD-тестирование, Vanessa СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    5384    SvVik    0    

Практика применения DevOps. Работа с SonarQube

DevOps SonarQube v8 1cv8.cf Бесплатно (free)

Во второй части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступил Виталий Подымников – он рассказал про процесс проверки качества кода и использование SonarQube для работы с ним.

07.12.2020    7312    arcius_7012    11    

Управление конфигуратором в режиме агента с помощью python

Администрирование данных 1С Архивирование (backup) Скрипты автоматизации v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    1975    Alex10166    2    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    5197    grumagargler    14    

Визуализация фич Vanessa Automation в StoryMapper

Agile (XP, SCRUM, Канбан) Сценарное тестирование BDD/TDD-тестирование, Vanessa ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    4060    oleynik.dv    7    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Сценарное тестирование v8 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    6847    ivanov660    4    

Как управлять качеством кода 1С, используя платформу SonarQube

Рефакторинг и качество кода SonarQube Бесплатно (free)

При быстром росте функциональности проводить визуальный Code-Review для обнаружения некачественного кода проблематично. О том, как автоматизировать проверку качества кода 1С с помощью платформы SonarQube на конференции Infostart Event 2019 Inception рассказал ведущий разработчик компании «Командор» Олег Тымко.

30.12.2019    11381    olegtymko    10    

RPA: программные роботы работы не боятся

Методология Управление Технологии Скрипты автоматизации Бесплатно (free)

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

28.10.2019    12145    bolefirenko    37    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода SonarQube EDT v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    19369    Stepa86    40    

Управляй качеством кода 1С с помощью SonarQube

Рефакторинг и качество кода SonarQube Россия Бесплатно (free)

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    56542    olegtymko    246