BF java-unit-test
Помощник по **согласованию стандартов** модульного тестирования Java. Используйте этот навык при написании, проверке, дополнении модульных тестов — независимо от того, упоминает ли пользователь конкретные фреймворки (unit test / JUnit / Mockito / тестовые случаи / как тестировать / что тестировать / сколько тестировать). Суть: унификация командных стандартов тестирования — использование одного набора методов проектирования (эквивалентные классы/граничные значения/таблицы решений/переходы состояний), одного набора по умолчанию (нативные утверждения JUnit 5, обязательная проверка по четырем измерениям), одного набора критериев остановки "сколько писать", чтобы качество тестов, создаваемых разными людьми/в разных диалогах, было одинаковым, отслеживаемым, проверяемым, а не каждый раз случайным. Охват: обязательные четыре измерения для метода (позитивные/негативные/граничные/исключительные), минимальный достаточный набор, обратная проверка покрытия, именование и организация тестов, границы Mock, оценка затрат/выгод "сколько писать". Вторичные триггеры: писать только happy path, дополнять тесты, не зная, сколько писать, писать кучу повторяющихся @Test вручную, тестировать только один-два варианта при множестве условных ветвленений, тестировать только нормальный поток для объектов с состоянием, использовать @MockBean только для чистого модульного тестирования, не уверены, насколько далеко следует писать тесты. Инструменты по умолчанию: утверждения по умолчанию используют нативные Assertions JUnit 5, только при утверждении содержимого коллекций / групповых утверждений по полям (одна логическая группа) переключаются на AssertJ; проекты Spring Boot используют spring-boot-starter-test (включает JUnit5+Mockito). Неприменимо: интеграционное тестирование/E2E (@SpringBootTest полный контекст), нагрузочное тестирование, тестирование фронтенда.
машинный переводПоказать оригиналСкрыть оригинал«Java 单元测试**规范对齐**助手。在编写、评审、补全单元测试时使用本技能—— 无论用户是否提到具体框架（unit test / JUn…»
Java 单元测试**规范对齐**助手。在编写、评审、补全单元测试时使用本技能—— 无论用户是否提到具体框架（unit test / JUnit / Mockito / 测试用例 / 怎么测 / 测哪些 / 写多少测试）。 核心：统一团队的测试规范——用同一套设计方法（等价类/边界值/决策表/状态迁移）、 同一套默认（JUnit 5 原生断言、四维度必检）、同一套"写多少"的停止标准， 让不同人/不同对话产出的测试质量一致、可溯源、可审计，而非每次碰运气。 覆盖：一个方法必测的四维度（正向/反向/边界/异常）、最小充分集、 覆盖率反向校验、测试命名与组织、Mock 边界、"写多少"的成本收益判定。 次级触发信号：只写 happy path、补测试不知道写几个、手写一堆重复 @Test、 多条件分支只测一两种、有状态对象只测正常流转、@MockBean 用于纯单测、 不确定测试该写到什么程度。 工具默认：断言默认用 JUnit 5 原生 Assertions，仅在集合内容断言/字段分组断言（同一逻辑组）时升级到 AssertJ； Spring Boot 项目走 spring-boot-starter-test（自带 JUnit5+Mockito）。 不适用：集成测试/E2E（@SpringBootTest 全量上下文）、性能测试、前端测试。
Помощник по согласованию стандартов модульного тестирования Java.
Как процесс F 35/100 · Не запустится — Скилл ссылается на файлы, которых нет в архиве: references/06, references/01, references/02
Как улучшить
- Скажите в description, КОГДА применять скилл («используй, когда…», примеры запросов): это главный сигнал для агента.
- В тексте есть ссылки на отсутствующие файлы: добавьте файлы или уберите ссылки.
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 8. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
- предупреждение
description-no-whendescription не говорит, КОГДА применять скилл (нет "use when / используй когда") - предупреждение
missing-refссылка на отсутствующий файл: references/06 - предупреждение
missing-refссылка на отсутствующий файл: references/01 - предупреждение
missing-refссылка на отсутствующий файл: references/02 - предупреждение
missing-refссылка на отсутствующий файл: references/03 - предупреждение
missing-refссылка на отсутствующий файл: references/04 - заметка
frontmatter-keyнеизвестное поле фронтматтера "slug" - заметка
frontmatter-keyнеизвестное поле фронтматтера "displayName" - заметка
frontmatter-keyнеизвестное поле фронтматтера "last_verified"
Процессный рейтинг: все десять параметров 35/100
- 0Инструменты и файлы. Не хватает 5 файла(ов): references/06, references/01, references/02
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 20Когда включается. Не сказано, при каком запросе скилл включается
- 100Шаги. Шагов: 31
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 1745 токенов
- 100Повторный запуск. Изменяющих операций нет
- low Разделов верхнего уровня: 12. Похоже на несколько доменов в одном скилле
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Формат ответа не описан: модель каждый раз решает сама
- +1Лицензия не указана
- +2Инструкции на одном языке
- +3Длина description 578 символов: достаточно сигнала, не съедает бюджет
- +4Структура: 13 заголовков
- +3Пошаговые инструкции: 31 пунктов
- +4Есть примеры (1 блоков кода)
- +4Справочные файлы упоминаются в инструкциях (6 из 6)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 61.