ovcharenko-di / 1coverage Goto Github PK

View Code? Open in Web Editor NEW

11.0 11.0 2.0 298 KB

Приложение OneScript для расчета покрытия исходного кода конфигураций 1С

License: MIT License

Gherkin 17.82% 1C Enterprise 80.41% JavaScript 1.77%

1c-enterprise coverage onescript

1coverage's Introduction

Hi there 👋

1coverage's People

Contributors

Stargazers

Watchers

Forkers

khorevaa neon-net

1coverage's Issues

Подготовить приложение под использование в opm

[DOCS] Указать корректные настройки vanessa-automation для подключения клиентов тестирования к серверу отладки

Обновить зависимость от ParserV8i и vanessa-runner

Текущие зависимости приводят к ошибке в команде init, когда в списке регистрируется новая ИБ

[BUG] Ошибка в команде init, если файл ibases.v8i пуст

Необходимо перехватить исключение от ParserV8i и продолжить

[BUG] Команда start не затирает PID, а всегда дописывает новые строки в файл

[BUG] Некорректное поведение команды stop

Если в файле PID более 3 записей, тест генерит исключение, но все равно отмечается как успешный

Сделать установку автоподключения предметов отладки в команде start

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

Без этого клиентские соединения запускаются без отладки, сбор замеров не выполняется.

Подключить инструменты CI (тестирование + sonar)

Предпочтительно на Actions

Работа в среде linux

Приложение должно корректно работать в среде linux

Заставить приложение работать с ИБ, которые не зарегистрированы в списке ИБ

Например, если ИБ создается с помощью runner init-dev --nocacheuse

[BUG] "Команда._Элементы" и "Форма._Элементы" может иметь тип Массив, а не только Соответствие

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

1coverage/src/1coverage/core/Классы/ОбработчикФайловКонфигурации.os

Line 292 in 12fa619

ИмяКоманды = Команда._Элементы["name"];

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

Сценарий: проверка разделения логов dbgs-proxy по файлам
Допустим я настроил произвольную ИБ для расчета покрытия
Когда я начал сбор замеров производительности через `1coverage init`
Тогда в каталоге логов dbgs-proxy есть файл 2020-01-20 14-43-21.log
И я останавливаю замер производительности командой к серверу отладки
Тогда в каталоге логов dbgs-proxy есть файл 2020-01-20 14-45-01.log
И я запускаю замер производительности командой к серверу отладки
Тогда количество файлов в каталоге логов dbgs-proxy не изменилось

Уметь запускать npm start из произвольного каталога

обнаружил ошибку в команде start

если выполнять ее в произвольном каталоге, то прокси не стартует, т.к. в этом каталоге отсутствует package.json

варианты решения:

копировать package.json в произвольный каталог
устанавливать правильный рабочий каталог для консольной команды npm start
указывать путь к package.json (если это возможно)

[BUG] команда start при указании относительного пути в параметре logpath работает некорректно

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

Обновить картинку со схемой работы в README

указать dbgs-proxy
переименовать файл с настройками отладки

Заполнить данные замеров по логам прокси также, как это делается сейчас
По исходному коду конфигурации заполнить "кэш" объектов метаданных (UUID, ИмяОбъекта, ИмяКоманды, ИмяФормы).
Желательно перебирать не все исходники конфигурации, а только те файлы, которые содержат uuid, которые есть в данных замеров (cat/grep + windows?)
Данные покрытия формировать по данным замеров с учетом этого кэша.
Сейчас данные покрытия формируются при обходе файлов исходного кода, а в них нет информации о типе модуля