Скил testing — пирамида с требованиями
Как скил testing структурирует верификацию на уровнях юнит-, интеграционных и E2E-тестов — и конкретные правила, не позволяющие моками создавать ложное ощущение безопасности.
Тесты, которые проходят, когда продакшн падает, хуже отсутствия тестов вообще — они создают уверенность в чём-то ложном. Скил testing построен вокруг устранения именно этого класса сбоев. Структура: входной файл плюс набор целевых фрагментов, каждый из которых закрывает отдельный тип проблемы.
Базовая пирамида знакома: 70% юнит-тестов, 20% интеграционных тестов, 10% E2E-тестов. Юнит-тесты мокают все внешние зависимости. Интеграционные тесты покрывают взаимодействие модулей с базой данных. E2E-тесты покрывают критические пользовательские сценарии. Эти пропорции — целевые показатели, а не ориентиры: CI падает при отсутствии или неуспешном прохождении тестов.
Проблема границы мока
В правилах мокирования есть одно ограничение, которое легко пропустить: никогда не мокать то, что тестируется. Если класс бага живёт в реальной интеграции — неверный клиент, неверная схема, неверный SQL-диалект — юнит-тест с моком пройдёт, а продакшн упадёт. Именно поэтому скил маршрутизирует конкретные сценарии в фрагмент live-smoke-gates.md: сырой SQL, код для нескольких источников данных, оркестрация Docker и операции массовой загрузки — всё это требует живого смок-теста, а не мока.
Вторая проблема границы — сериализация на стороне драйвера. Когда юнит-тест перехватывает параметры мока БД-драйвера и проверяет инварианты формата колонки, параметры захватываются до применения драйвером собственной сериализации. Реальный драйвер может JSON-сериализовать массив при вставке в колонку; мок молча принимает сырой массив. Скил предписывает вспомогательную функцию simulateDriverBind(p), воспроизводящую правила сериализации драйвера со ссылкой на его документацию — для каждого юнит-теста DB-записи с контрактом на формат колонки.
Самоверифицирующие утверждения
Утверждения существования — «элемент рендерит какой-то текст», «счётчик не пуст» — ловят только случай, когда вообще ничего не отрендерилось. Они проходят, даже когда система сломана. Скил требует самоверифицирующих утверждений: после инициирующего взаимодействия опросить перевёрнутое целевое состояние. Тест чекбокса должен опрашивать isChecked() против известного противоположного состояния до клика, а не просто подтверждать, что где-то есть текст. Источник правила конкретный: утверждение, сначала написанное как «счётчик рендерит какой-то текст», проходило даже когда тогл был явно сломан.
Маршрутизация по фрагментам
Скил намеренно держит входной файл коротким и маршрутизирует к фрагментам по необходимости. tdd-discipline.md охватывает цикл RED-GREEN-REFACTOR и заблаговременно отвечает на стандартные отговорки против подхода «тест сначала». silent-failure-detection.md обрабатывает CLI-обёртки, завершающиеся с кодом 0 при ошибке и пишущие сообщение об ошибке в stdout. bats-and-spec-lint.md — тестирование шелл-скриптов. triaging-legacy-failures.md предоставляет трёхстадийный триаж для унаследованных красных тест-сьютов. Загрузка только нужного фрагмента снижает стоимость контекста в каждом цикле QA или реализации.
Скил testing напрямую связан со скилом systematic-debugging — фаза 4 систематической отладки требует создания падающего теста до любого исправления. Выбор тестовых фреймворков для конкретного стека — в скиле tech-stack. Общий воркфлоу Datarim описан в посте что такое Datarim.