Тестовый полигон: сверка с рекомендацией «Типизация кода»

[nixel2007]

Методическая рекомендация «Типизация кода» разобрана на 138 проверяемых пунктов, на каждый заведён отдельный тест. Номер пункта стоит в @DisplayName, поэтому соответствие «пункт — тест» проверяется машинно: пропусков, дублей и лишних тестов нет.

Зачем

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

Как устроено

Тест выражает требование рекомендации, а не наше текущее поведение:

• имена типов — как их пишет рекомендация: ТабличнаяЧасть, СтрокаТабличнойЧасти, ФормаКлиентскогоПриложения, ДанныеФормыСтруктура, ДанныеФормыЭлементКоллекции, ТабличныйДокумент;
• поведение — из её же примеров: Форма.Объект.Ссылка, Форма.Элементы.Артикул, Список.ТекущиеДанные.Артикул, Адрес.Улица, Элемент.Видимость, реквизит строки табличной части;
• пункты про контроль типов требуют диагностику по ключу (MissingType, TypeChange, IncompatibleArgumentType, DeclaredTypeMismatch и др.);
• пункты про возможности редактора требуют кодовое действие по идентификатору (source.generateMethodDescription, source.showDescriptionStructure, source.enableStrictTypes).

Ключи диагностик и идентификаторы действий пока предложены — уточняются при реализации соответствующих пунктов.

Раздел рекомендации	Тест-класс	Тестов	Зелёных	Красных
Как это работает	SpecSection2Test	14	13	1
Возможности документирующих комментариев	SpecSection3Test	37	34	3
Практики: данные и коллекции	SpecSection4DataObjectsTest	39	34	5
Практики: формы, контейнеры, выборки	SpecSection4FormsAndContainersTest	16	12	4
Пункты, проверяемые в модуле формы	SpecFormModuleTest	4	4	0
Контроль типов	SpecStrictTypingControlTest	18	1	17
Возможности редактора	SpecEditorFeaturesTest	10	6	4
Итого		138	104	34

Состояние

104 зелёных, 34 красных (на ребейзе от 2026-08-23). Красный тест означает, что пункт рекомендации у нас не закрыт; падений по ошибкам нет — все красные это расхождение ожидания с фактом.

CI на этой ветке будет красным — это ожидаемо. Полигон не предназначен для зелёного прогона целиком: он чинится по мере реализации пунктов. Прогон всего пакета types (1873 теста) показывает, что ни один существующий тест не сломан: все 34 падения — внутри классов Spec*.

Тяжелее всего раздел «Контроль типов» — 17 красных из 18: он целиком про диагностики, которых пока нет. Раздел «Пункты, проверяемые в модуле формы» закрыт полностью.

Красные по пунктам:

• Как это работает: 2.11.
• Документирующие комментарии: 3.31, 3.32, 3.33 — все три про динамический список: его текущие данные и строку его таблицы. Ждали источник данных списка от mdclasses.
• Данные и коллекции: 4.23, 4.30, 4.32, 4.38, 4.42.
• Формы, контейнеры, выборки: 4.49 и 4.50 (имя формы в переменной и имя основной формы), 4.64, 4.66.
• Контроль типов: 2.18–2.24, 2.30, 4.3, 4.12, 4.18, 4.51, 4.52, 4.55, 4.61, 4.62, 4.68.
• Возможности редактора: 2.14, 2.16, 2.17, 2.25.

Сверка фикстур с буквой рекомендации

Часть красных оказалась дефектами самого полигона, а не расхождением с рекомендацией; они исправлены:

• тела функций-заглушек (3.15-3.17, 3.20, 4.4, 4.5). Рекомендация записывает эти примеры одной сигнатурой, без тела. Заглушка Возврат Неопределено подмешивала в объединение свой тип. Тела приведены к объявленным типам;
• 3.32 объявлял параметр обобщённым ТаблицаФормы, тогда как рекомендация пишет здесь ссылку на конкретный элемент формы. С обобщённым типом колонки конкретного списка неизвестны в принципе, и проверка не могла пройти ни при какой реализации;
• 4.45, 4.47, 4.48 сверяли имя типа с обобщённым (ФормаКлиентскогоПриложения, ДанныеФормыСтруктура), а система типов отдаёт тип конкретной формы — строго более точный. Сверка переведена на вхождение, как уже сделано в 3.20, 3.22, 3.23 и 3.29-3.33.

Фикстуры

• src/test/resources/types/spec/SpecSection{2,3,4}.bsl — пробы по разделам рекомендации;
• в модули СправочникСМенеджером добавлены документированные методы — для ссылок вида Модуль.Метод.Параметр;
• в форму Документ1.ФормаДокумента добавлен реквизит с типом «Произвольный» — для пунктов 4.59 и 4.60.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Test Results

 3 465 files   -   651   3 465 suites   - 651   44m 56s ⏱️ - 7m 36s
 4 403 tests +  138   4 298 ✅ +  104   71 💤 ± 0   34 ❌ + 34 
22 015 runs   - 3 575  21 486 ✅  - 3 674  359 💤  - 71  170 ❌ +170 

For more details on these failures, see this check.

Results for commit 30e945e. ± Comparison against base commit 42a7549.

♻️ This comment has been updated with latest results.

[nixel2007]

Два пункта, где ожидание теста не подпирается текстом рекомендации

Оба оставлены красными — правка меняет смысл пункта, поэтому нужно решение.

4.23 «Обращение к колонке по имени в переменной». Тест требует, чтобы у СтрокаТаблицы[ИмяКолонки] типа не было вовсе (isEmpty), со ссылкой на то, что рекомендация этого не требует. Но рекомендация про этот случай говорит только одно: такие методы — исключение из правила «обращаться к колонкам напрямую», когда набор колонок неизвестен в рантайме. Про тип выражения там не сказано ничего. У нас параметр объявлен как См. ТоварыДляСписания, колонки известны, и мы отдаём объединение их типов — СправочникСсылка.Справочник1, Число. Это не противоречит рекомендации.

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

4.50 «Имя основной формы даёт общий тип формы». Рекомендация пишет, что ссылка на основную форму (Справочник.X.ФормаОбъекта) даёт общий ФормаКлиентскогоПриложения и «весь контекст формы не будет доступен». У нас ПолучитьФорму("Справочник.Справочник1.ФормаОбъекта") резолвится в конкретный тип формы — строго точнее, чем описывает рекомендация.

Здесь нельзя просто перевести сверку на вхождение, как в 4.47/4.48: тогда пункт перестанет отличаться от них, а весь смысл пары 4.49/4.50 против 4.47/4.48 — в контрасте «общий тип против конкретного». Правильнее либо переформулировать пункт как «мы точнее рекомендации», либо оставить красным как осознанное расхождение.

Соседний 4.49 (имя формы в переменной) — настоящий пробел: мы не даём ничего, тогда как рекомендация обещает хотя бы общий тип.