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

21.05.21

Разработка - Рефакторинг и качество кода

На 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С".

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1149    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2675    ZhokhovM    4    

8

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1909    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6968    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4346    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9586    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

11.07.2023    2214    magic1s    32    

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

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

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

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

У меня уже давно руки чешутся сделать свой отладчик и профайлировщик для 1С Предприятие 8 (ибо типовые не очень устраивают; впрочем они меня не устраивают даже в MS Visual Studio или IntelliJ IDEA - хотя меньше, чем в 1С) - по уже частично разобранному, в данной статье/докладе, механизму получения исполняемых строк кода, можно сделать половину того, что хотелось бы. Остальное наверняка можно тоже - просто нужно глубже поковыряться в API внешнего HTTP-отладчика.
Данная статья вдохнула в меня надежду, что это реально сделать (и не бесконечно-сложно). Вот только я не Java-программист :-(
8. roman72 379 28.05.21 12:53 Сейчас в теме
EDT вроде как в свободном доступе нынче.
По крайней мере, для владельцев любой программы 1С точно.
9. kraynev-navi 647 31.05.21 21:06 Сейчас в теме
Отличный инструмент! Вот жаль только, что релиз не менялся аж с 2020. Но с форка утащил более новый.
10. user1596477 02.07.21 14:38 Сейчас в теме
Стандартный вопрос автору работает ли с обычными формами? Если нет, то планируется ли?
VSK_Insurance_House; +1 Ответить
11. itsys 45 05.03.22 06:16 Сейчас в теме
Поделитесь опытом запуска на CI, конвейер встает на запуске расчета покрытия:
Общая настройка выглядит сейчас так:
- start "" Coverage41C start -i %BASE1C% -u http://127.0.0.1:1550 -s %CI_PROJECT_DIR%\SML -p %CI_PROJECT_DIR% -o %TestDIR%\genericCoverage.xml -r EDITABLE_SUPPORT_ENABLED
- start "" /wait "%V8%" %BASECON% /N%Admin1C% /Execute "C:\Program Files\OneScript\lib\vanessa-automation\vanessa-automation.epf" /TESTMANAGER /C"StartFeaturePlayer;VBParams=%TestDIR%\params.json"
- start "" /wait Coverage41C stop -i %BASE1C% -u http://127.0.0.1:1550
- call sonar-scanner.bat -Dsonar.projectBaseDir=%CI_PROJECT_DIR% -Dsonar.coverageReportPaths=%TestDIR%\genericCoverage.xml

Получаем в окне запуска:
Unmatched argument at index 8: 'D:\GitLabRunner\builds\trsPAwsa\0\edt\sml'
Недостаточно ресурсов памяти для обработки этой команды.


В окне остановки:
[main] INFO com.clouds42.Commands.SendMessageCommand - Trying to send command to main application...
java.io.IOException: Couldn't open pipe for \\.\pipe\COVER_SML_STAGING_http___127.0.0.1_1550 (2)
at org.scalasbt.ipcsocket.JNAWin32NamedPipeLibraryProvider.CreateFile(JNAWin32NamedPipeLibraryProvider.java:86)
at org.scalasbt.ipcsocket.Win32NamedPipeSocket.createFile(Win32NamedPipeSocket.java:29)
at org.scalasbt.ipcsocket.Win32NamedPipeSocket.<init>(Win32NamedPipeSocket.java:89)
at com.clouds42.Commands.SendMessageCommand.call(SendMessageCommand.java:63)
at com.clouds42.Commands.SendMessageCommand.call(SendMessageCommand.java:42)
at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
at picocli.CommandLine.access$1300(CommandLine.java:145)
at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
at picocli.CommandLine.execute(CommandLine.java:2078)
at com.clouds42.Coverage41C.main(Coverage41C.java:47)
Недостаточно ресурсов памяти для обработки этой команды.
Показать
12. itsys 45 05.03.22 11:00 Сейчас в теме
(11)
Разобрался, моя ошибка путь к проекту вместо -P указал через -p :)

Отрабатывает нормально, но при закрытии отчета получается следующее:
$ start "" Coverage41C start -i %BASE1C% -u http://127.0.0.1:1550 -s %CI_PROJECT_DIR%\SML -P %CI_PROJECT_DIR% -o %TestDIR%\genericCoverage.xml -r EDITABLE_SUPPORT_ENABLED
$ start "" /wait "%V8%" %BASECON% /N%Admin1C% /Execute "C:\Program Files\OneScript\lib\vanessa-automation\vanessa-automation.epf" /TESTMANAGER /C"StartFeaturePlayer;VBParams=%TestDIR%\params.json"
$ start "" /wait Coverage41C stop -i %BASE1C% -u http://127.0.0.1:1550
^CTerminate batch job (Y/N)?
Uploading artifacts for failed job
Uploading artifacts...
Runtime platform arch=amd64 os=windows pid=16744 revision=5316d4ac version=14.6.0
jUnit\SML-junit.xml: found 1 matching files and directories
Uploading artifacts as "junit" to coordinator... ok id=26940 responseStatus=201 Created token=hX8DPNzD
ERROR: Job failed: exit status 3221225786

Посылается Ctrl+C в активное окно выполнения и в результате все прерывается.
13. itsys 45 09.03.22 11:15 Сейчас в теме
(12)
Добился нормальной стабильной работы.

Окончательный вариант, может кому пригодится:
- start "" cmd /c Coverage41C start -i %BASE1C% -u http://127.0.0.1:1550 -s %CI_PROJECT_DIR%\SML -P %CI_PROJECT_DIR% -o %TestDIR%\genericCoverage.xml -r EDITABLE_SUPPORT_ENABLED
- start "" /wait "%V8%" %BASECON% /N%Admin1C% /Execute "C:\Program Files\OneScript\lib\vanessa-automation\vanessa-automation.epf" /TESTMANAGER /C"StartFeaturePlayer;VBParams=%TestDIR%\params.json"
- start "" cmd /c Coverage41C stop -i %BASE1C% -u http://127.0.0.1:1550
14. SolomoH 11.10.22 16:11 Сейчас в теме
Всем привет, оставлю свою(альтернативную) версию запуска coverage41C с использованием gitlab ci.
1. # Запуск файла отладки dbgs.exe для коннекта Coverage41C
- echo "Запуск файла отладки dbgs.exe"
- "C:\Program Files\1cv8\8.3.20.1914\bin\dbgs.exe" --port=1550
# Сначала обязательно нужно запустить сервер отладки на необходимом порту, а уже только потом приступать к запуску Coverage41C.
# Запуск Coverege41C
- echo "Запустим Coverege41C"
- Coverage41C start -i DefAlias -u http://127.0.0.1:1550 -s $CI_PROJECT_DIR\$PROJECT_NAME\src -P $CI_PROJECT_DIR -o $CI_PROJECT_DIR\$PROJECT_NAME.xml
Оставьте свое сообщение