Парсера запросов не хватает

Параметры можно искать по символу &. Проблемы могут быть с текстом запроса собираемым кодом.

Сюда же можно добавить случай

• в тексте запроса нет использования параметра, а кодом 1С он все равно устанавливается
  • 1С ошибку не выдает, конечно
  • но и такое использование неверно и может путать разработчиков

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

@theshadowco назначай на меня, правило практически реализовано.

@artbear 1) я не думаю, что эту диагностику стоит делать без cfg. текущая реализация страшноватая.
2) перестань, пожалуйста, использовать TestUtils.getDocumentContext(sample). Если ты хочешь срабатывания по тестам, то лучше уж клади запросы в разные файлы, чем вот так. Причем это уже два раза обсуждали.

@nixel2007 1 cfg здесь особо не поможет.
текущая реализация вполне себе адекватно ищет срабатывания и не является нагрузочной.

2 по TestUtils.getDocumentContext(sample) странная позиция.
почему в других диагностиках принимается\разрешается использовать? по той же cfg, например, использование сделано.

напомню, что TestUtils.getDocumentContext(sample) очень удобно юзать именно для разработки и отладки в качестве мелких и простых юнит-кейсов.
и я в общем тест-файле эти диагностики также помещаю, а не только в юнит-тестах их оставляю.

например, для лечения ФП\ФН очень полезно использовать именно этот вариант.

как мейнтейнер подумай о разработчиках правил, пожалуйста!
насколько проще разрабатывать\дорабатывать в рамках юнит-тестов вместо общей кучи всех тест-кейсов в одном тесте.

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

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

почему в других диагностиках принимается\разрешается использовать? по той же cfg, например, использование сделано.

потому что пропустил.

напомню, что TestUtils.getDocumentContext(sample) очень удобно юзать именно для разработки и отладки в качестве мелких и простых юнит-кейсов.
и я в общем тест-файле эти диагностики также помещаю, а не только в юнит-тестах их оставляю.

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

И я обязательно использую этот файл, помещая туда все тест-кейсы.

тем самым ты вносишь дублирование тест-кода. что уже не есть хорошо.

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

До перехода на jdk17 в тестах и появления текст-блоков это все еще и выглядит страшно.

причем это обсуждение возникает уже третий раз за год-полтора, и насколько я помню, от кого-либо из @1c-syntax/bsl-ls не было поддержки предложения по такому подходу к тестам. поправьте меня, если это не так.

Я против фикстур в самом тесте - увеличение рзамера тестового класса (читай усложение ревью).