chimera-write-the-check-before-the-code

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

ПаттернПроисхождение: cleanСостояние: activev0.1.0 · Apache-2.0

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

Когда это вспоминается

сейчас начну делать фичу
определяю, что считать готовым
пишу тест после кода
в задаче нет критериев приёмки

Ценность обычно лежит в разделах «Избегать» и «Проверить». «Делать» — это раздел, который пишут все.

Текст карточки выше — перевод. Английский оригинал — это то, что импортирует командная строка, что читает агент во время работы и что подтверждает хеш ниже.

Повод

Вы собираетесь реализовать нечто, чьё «готово» ещё не наблюдаемо: функциональность, исправление бага, рефакторинг, заявляющий о сохранении поведения. Больнее всего это кусает, когда автор и единственный рецензент — один и тот же процесс: агент, работающий в одиночку, или личный коммит, который никто не прочтёт.

Это не относится к разведочному спайку. У исследования, чья цель — выяснить, что вообще возможно, ещё нет критерия приёмки, и придумывание его заранее лишь якорит вас к первой идее. Пишите проверку, когда спайк кончился и начинается настоящая работа.

Эта карточка — о проверке, которой ещё нет. Её сестра, chimera-prove-the-test-discriminates, — о проверке, которая уже есть и может быть пустой; к ней вы обращаетесь после починки, чтобы показать, что тест без неё падает. Тот же инстинкт, противоположные концы работы.

Делать

Прежде чем трогать реализацию, запишите критерий как то, что может упасть: тест, утверждение, команду, у которой меняется код выхода, запрос с ожидаемой строкой. Проза — не проверка: «endpoint должен стать быстрее» не проверка, а «p95 меньше 200 мс на наборе фикстур, измерено существующей командой bench» — проверка.
Скажите, откуда берётся наблюдение. Из машины, а не из вашего прочтения диффа.
Запустите проверку сейчас, против неизменённого кода. Она обязана упасть. Если она проходит, то либо поведение уже существует — и тогда стоп, строить нечего, — либо проверка проверяет не то, что вы думаете.
Прочтите сообщение об ошибке. Она должна падать по задуманной причине, а не на ошибке импорта, отсутствующей фикстуре или опечатке в имени теста. Красное по неверной причине — это переодетое зелёное.
Влейте проверку до реализации, отдельным коммитом. Как только реализация существует, проверка становится редактируемой под неё — и её отредактируют.
Реализуйте. Готово — когда проверка проходит, а не когда код выглядит законченным.

Избегать

Писать утверждение потом, из вывода:


normalize("  Foo ")        # -> "foo"

# test transcribed from that observation
assert normalize("  Foo ") == "foo"

Такое утверждение не может упасть на том коде, с которого оно списано. Оно фиксирует поведение вместо требования и потому остаётся зелёным сквозь любой баг, относительно которого реализация внутренне последовательна. Если требованием была нормализация NFKC, а вы выпустили strip().lower(), этот тест будет соглашаться с вами вечно.

Избегайте также критерия, который пересказывает изменение, — «готово, когда функция добавлена», «готово, когда миграция выполняется». Оба удовлетворяются пустым телом.

Проверить

Два двоичных вопроса, оба отвечаются по репозиторию:

Видели ли вы, как проверка падает, пока реализации ещё не было? Если момента, когда она была красной, не существует, у вас нет свидетельства, что она может краснеть.
Осталась бы проверка верной, если бы функциональность построили совершенно иначе? Проверка, называющая внутренности — приватный вызов, строку лога, точный SQL, — привязана к вашему решению, а не к требованию, и будет мешать следующему рефакторингу, ничего при этом не ловя.

Конкретно: git log показывает, что проверка влита не позже реализации, а откат одного лишь коммита с реализацией красит набор тестов.

Риск

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

Есть и простая цена. Для исправления опечатки или правки документации писать проверку первой — обряд, за который никто не платит. Карточка окупается, когда поведение достаточно несущее, чтобы кому-то стало плохо от неверного «готово».

Как применить

Карточка — это данные. Склонируйте репозиторий и импортируйте её по пути: всё, что приходит по сети, считается заражённым и удерживается до одобрения — это и есть желаемое поведение, и поэтому здесь нет установщика в одну строку.

$git clone https://github.com/brcampidelli/chimera-agent.git

$chimera skills-import chimera-agent/skills/chimera-write-the-check-before-the-code/SKILL.md

Целостность

SHA-256 файла в опубликованном виде. Импортёр может проверить, что полученное совпадает с показанным на этой странице.

95d0a1b750e25af7651e85d26106a91f02f563ab1a1422edc4133d16942b67d7

Читать карточку в репозитории →