chimera-test-the-wiring-not-the-class

Вы построили компонент, до которого production добирается опосредованно: через фабрику, реестр, загрузчик плагинов, флаг конфигурации, роутер, точку входа CLI, контейнер внедрения зависимостей. Ваши тесты конструируют его напрямую и вызывают его методы.

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

Это не относится к чистой функции, которую вызывающие импортируют и вызывают напрямую. Там импорт и есть связывание, и unit-тест его покрывает. Не относится это и к случаю, когда вы намеренно тестируете алгоритм в изоляции: такие тесты верны и должны остаться; карточка утверждает лишь, что сами по себе они недостаточны.

1. Назовите точку входа, до которой пользователь действительно доходит: подкоманду CLI, HTTP-маршрут, цикл запуска агента, запланированную джобу. Запишите её до того, как писать тест.

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

3. Стройте объект так, как его строит production, — вызывайте настоящую фабрику или загрузчик конфигурации:

   # WRONG — proves the class, not the wiring: the component is handed to the thing under test,
   # so the test passes whether or not anything in production ever hands it over.
   assert "reminder" in render(feature=Feature(text="reminder"))
   
   # RIGHT — build it the way the entry point builds it, then look for the same observable
   assert "reminder" in build_the_real_way(config).render()
   

   Собственный случай Chimera стоит назвать, потому что класс никогда не был сломан. У skill cards были работающий retriever, работающее хранилище и работающий инжектор — а chimera/config.py:244 содержит skill_cards: bool = Field(default=False, ...), поэтому на стандартной установке ничего никогда не подставлялось. Все unit-тесты проходили. Измерение, которое в итоге это поймало, посчитало отчеканенные навыки против подставленных и получило 39 против нуля.

4. Проверяйте наблюдаемое, которое может появиться, только если до компонента дошли: текст в собранном промпте, записанную строку, строку лога, код выхода.

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

Тесты через точку входа медленнее, тяжелее в отладке и хуже локализуют: когда такой падает, вы знаете, что функция сломана, но не знаете, который из десяти компонентов её сломал. Это реальная цена, и неверная реакция на эту карточку — удалить свои unit-тесты в пользу end-to-end. Держите и те и другие: тест связывания сообщает, что сломалось, unit-тест — что именно.

Проход через настоящую точку входа может к тому же задеть то, что в CI задевать не хочется: платный API, живую базу, файловую систему за пределами песочницы. Если единственный способ дойти до точки входа — потратить деньги или изменить production, не форсируйте; покройте вместо этого функцию-сборщик напрямую и примите, что вы на шаг не дошли до настоящего пути.

И эта карточка ловит достижимость, а не корректность. Функция может быть безупречно связана с точкой входа и всё равно выдавать неверный ответ, так что зелёный тест связывания — не лицензия пропускать проверку того, что вывод на самом деле говорит.