Читаю книгу AI Driven Swift Architecture и в ее фундаменте стоят тесты. Я уже писал много раз, что логичным шагом валидации сгенерированного кода будут автотесты.
Автор книги iOS Unit Testing такого же мнения. Он считает, что инженерная дисциплина никуда не уйдет в мире ии, а скорее преобразится. ИИ нужно валидировать и апрувить. В хороших проектах он усливает плюсы, а в плохих минусы.
Пока мы суетливо и бессистемно приходим к похожим идеям, автор делится новой методологией через LLM. Они не могут за нас принимать решения, видить пограничные кейсы. Это как раз отлично решают автотесты.
LLM по умолчанию оптимизированы под корректность, читаемость и «конвенциональные best practices», но не под продвинутые эвристики TDD — когда тест устарел из-за триангуляции, когда более общий тест поглощает частные. Это решает человек.
Гайд по тестам:
1️⃣ CLAUDE.md это не документация, а правила, паттерны и другие описания требований к тестам
2️⃣ Transformation Priority Premise - тоже записывается в CLAUDE.md, и в примере Claude действительно начинает каждый шаг с чтения нужной секции перед генерацией.
3️⃣ Рефакторить надо и тесты. На уровне TDD недостаточно сказать "отрефактори", ассистент должен понимать зачем.
Хороший промпт называет проблему, привязывает ее к теории (а не к личному вкусу), ставит учебную цель, ограничивает рамкой и заканчивается "покажи изменения до применения".
4️⃣ Не сохраняй тесты как артефакты
Тесты должны эволюционировать вместе с архитектурой, а не цементировать ее и делать неповоротливой.
5️⃣ Перед применением теста пойми что они тестируют
Это поможет тебе не потерять контроль что происходит в коде
6️⃣ Правильность важнее колличества
Цель TDD это не количество тестов, а правильные тесты. Те, что ясно описывают поведение и защищают от регрессий.
7️⃣ Claude отлично исполняет четко заданные инструкции. Но какие инструкции приоритетны и как они описаны уже решает разработчик.
8️⃣ Изучите триангуляцию тестов. Уточняйте ее. Это увеличивает и ваше понимание, и контекст проекта для LLM.