столько тестового кода приходится на каждую строку рабочего кода SQLite
SQLite — самая распространённая СУБД в мире: миллиарды устройств, браузеры, телефоны, самолёты, и даже техника за пределами Земли. Такая надёжность держится не на удаче, а на одной из самых дисциплинированных систем тестирования в индустрии. Этот документ разбирает её по уровням — как универсальный ориентир, к которому может стремиться любая продуктовая команда.
Девиз SQLite — «Маленькая. Быстрая. Надёжная. Выберите любые три». Третье свойство стоит на простой и неудобной мысли: база данных помнит ошибки.
Упавший сервер можно перезапустить. Повреждённую запись — нет. Стоимость дефекта в СУБД асимметрична: ошибка на проде не просто роняет процесс, она тихо портит данные, которые будут читать годами. Поэтому всё тестирование выстроено вокруг одной цели — не дать дефекту дожить до релиза.
Из этого следует второй принцип. Легко написать движок, который работает на корректных входных данных и исправном железе. Трудно — тот, что ведёт себя предсказуемо, когда заканчивается память, отказывает диск, пропадает питание посреди записи или на вход прилетает враждебный мусор. Большая часть усилий направлена именно на это «когда всё ломается».
Полное покрытие здесь работает как страховка скорости, а не только качества: разработчик может смело переписать одну часть движка, зная, что тесты немедленно поймают регресс в любой другой. Без этого многие улучшения последних лет были бы слишком рискованными, чтобы их вообще пробовать.
Сами авторы SQLite прямо предупреждают: поддерживать 100% MC/DC дорого и трудоёмко, и для типового приложения это, скорее всего, не окупается. Оправдано это для инфраструктурной библиотеки, развёрнутой на миллиардах устройств, где цена ошибки огромна, а сама природа продукта — «помнить» прошлое.
Поэтому правильное чтение этого документа — брать принципы, а не цифру. Цель не в том, чтобы завтра достичь 100% покрытия, а в том, чтобы понимать, какие уровни защиты существуют, и осознанно выбирать, до какого доходить, исходя из цены ошибки в своём продукте.
Ключевое решение SQLite — не наращивать один гигантский набор тестов, а держать четыре независимо разработанных и сопровождаемых стенда. Логика проста: у любого набора тестов есть слепые зоны, но у четырёх разных стендов они разные. Разнообразие углов проверки ценнее, чем суммарный объём. Это инженерная версия «правила Линуса»: при достаточном числе независимых наблюдателей любой баг становится мелким.
Оригинальный набор, живёт в том же дереве исходников, что и ядро. Основной инструмент разработки: именно его гоняют чаще всего. Перед каждым коммитом разработчик прогоняет подмножество veryquick — оно ловит большинство ошибок за минуты, а не часы.
Набор на C, дающий 100% покрытие ветвей и 100% MC/DC ядра. Главная особенность: TH3 тестирует скомпилированный объектный код через публичные интерфейсы, а не исходники — то есть проверяет в том числе, что баг не внёс сам компилятор. Девиз — «тестируй то, на чём летаешь, и летай на том, что тестируешь». Работает на embedded-платформах без поддержки рабочих станций.
Прогоняет огромные объёмы SQL одновременно против SQLite и нескольких других СУБД — PostgreSQL, MySQL, SQL Server, Oracle 10g — и сверяет, что все вернули одинаковый ответ. Это решает фундаментальную проблему: «а как вообще узнать правильный ответ на миллион запросов, не прописывая его вручную».
Фаззер на базе libFuzzer с собственным структурно-осведомлённым мутатором. В отличие от других фаззеров, мутирует и SQL, и сам файл базы данных одновременно — и за счёт этого добирается до состояний ошибок, недостижимых иначе. Держится запущенным на трунке постоянно.
Это не лестница, где, поднявшись выше, бросаешь нижние ступени. Это эшелонированная оборона — слои, работающие одновременно. Каждый ловит свой класс дефектов; вместе они не оставляют зазоров.
Базовый слой: даёт ли движок правильный ответ на правильный вход.
veryquick (~304 тыс. кейсов) гоняется перед каждым коммитом — достаточно, чтобы поймать большинство ошибок за минуты.Как проверить правильность ответа, когда вручную прописать его невозможно.
Большинство багов живёт на краях диапазонов, а не в их середине.
testcase() гарантирует, что покрыты обе стороны каждой границы.Поведение, когда отказывает окружение: память, диск, питание.
malloc() падает на N-й аллокации; подменный VFS симулирует отказ диска и потерю питания, переупорядочивая и портя несинхронизированные записи. В цикле точка отказа сдвигается, пока операция не пройдёт целиком. После каждого прогона — integrity_check.Устойчивость к враждебному, бессмысленному и злонамеренному вводу.
dbsqlfuzz мутирует SQL и файл БД сразу; jfuzz портит JSONB-блобы; сторонние фаззеры (напр. М. Риггера) находят не падения, а неверные ответы. «Интересные» исторические кейсы прогоняются на каждом make test через fuzzcheck.Что делает движок, когда ему подсовывают битый файл хранилища.
SQLITE_CORRUPT без переполнений буфера и разыменования NULL.Проверки, встроенные внутрь кода и работающие во время исполнения.
assert() на пред/постусловия и инварианты циклов (в debug-сборке; в проде выключены — с ними движок втрое медленнее). Прогоны под Valgrind. Проверки неопределённого поведения: -fsanitize=undefined, -ftrapv, /RTC1, на 32/64-бит и big/little-endian. Авто-детект утечек памяти, дескрипторов и мьютексов на каждом прогоне.Однажды исправленный баг не должен вернуться никогда.
// слои 01–03 → корректность · 04–06 → устойчивость · 07–08 → внутренняя дисциплина
Когда говорят «у нас XX% покрытия», почти всегда имеют в виду покрытие операторов (statement coverage) — какой процент строк хоть раз выполнился. SQLite держит куда более строгую метрику — покрытие ветвей (branch coverage). Разница принципиальна. Возьмём строку:
Один проход, где условие истинно, даёт 100% покрытия операторов — строка «протестирована». Но чтобы покрыть все ветви, нужно минимум три случая:
100% покрытия ветвей всегда влечёт 100% операторов, но не наоборот. Поверх этого SQLite добивается ещё и MC/DC (Modified Condition/Decision Coverage) — стандарта, применяемого в авиационном ПО: каждое условие в решении должно быть показано как независимо влияющее на результат.
Защитный код не удаляют ради метрики. Условия, которые в проде всегда истинны/ложны, помечают макросами ALWAYS()/NEVER(). Они исключаются из подсчёта покрытия, но в debug-сборке падают с ошибкой, если предположение нарушено.
gcov как мета-тест. Прогон с замером покрытия тестирует не сам SQLite, а качество набора тестов — доказывает, что тесты доходят до каждой ветви. Реальная проверка движка идёт отдельной сборкой, в боевой конфигурации компилятора.
Мутационное тестирование. Каждую инструкцию ветвления по очереди меняют на «всегда» или «никогда» и проверяют, что тест это заметил. Если не заметил — либо ветка лишняя (можно удалить), либо тест слаб. Плюс весь набор гоняется с включёнными и выключенными оптимизациями: ответ обязан совпасть.
Фаззинг и 100% MC/DC тянут в разные стороны. MC/DC не любит защитный код с недостижимыми ветвями — а именно такой код спасает от фаззера. Код, идеально проходящий fuzzing, обычно имеет заметно меньше 100% MC/DC. SQLite держит оба, но большинство процессорного времени сегодня уходит на fuzzing. Идеального «и то, и другое разом» не существует — это всегда осознанный компромисс.
Перед каждым релизом проходится чек-лист примерно из 200 пунктов, вручную. Часть отмечается за секунды, часть запускает тесты на много часов. Подход вдохновлён книгой «Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям» Атула Гаванде.
Принципиально, что список сознательно не автоматизирован полностью. На верхнем уровне нужен человек, который смотрит на вывод тестов и спрашивает: «А это правда корректно?». Бывает, что тест формально проходит, но человек замечает рядом проблему. Список постоянно эволюционирует — каждая новая обнаруженная проблема добавляет в него пункт.
Статический анализ им почти не помог. По их собственному признанию, больше багов было внесено при попытках убрать предупреждения анализаторов, чем найдено этими анализаторами. Вывод не «статический анализ бесполезен везде», а более тонкий: набор тестов был настолько силён, что отдача от статического анализа на его фоне оказалась мала. Сначала — тесты.
100% MC/DC копировать слепо не нужно — это для инфраструктуры с ценой ошибки в миллиарды устройств. Переносится не цифра, а принципы. Вот порядок, в котором они окупаются.
Минимальная практика, которая окупается сразу же и не даёт исправленным ошибкам вернуться. Если внедрять что-то одно — это.
Что происходит при отказе сети, пустом ответе, таймауте, битых данных. Большинство продакшен-инцидентов живёт именно здесь.
Несколько независимых углов (юнит + интеграция + дифференциальный + фаззинг) ловят то, что пропускает каждый по отдельности. Не наращивайте один тип бесконечно.
Старая реализация, эталонный сервис, вторая независимая ветка логики — если ответ можно сверить автоматически, не прописывайте эталоны руками.
Как метрика — измеряйте ветви, а не строки. «90% строк» и «90% ветвей» — это две очень разные степени уверенности.
Чек-лист релиза и финальный взгляд живого человека, спрашивающего «это правда корректно?», ловят то, что зелёный CI пропускает.
Уровень усилий на тестирование должен соответствовать цене ошибки в конкретном продукте. SQLite — крайняя точка спектра, где эта цена максимальна. Ваш продукт почти наверняка не требует 100% MC/DC — но эта карта показывает, какие рубежи обороны вообще существуют, чтобы вы осознанно выбирали, до какого дойти, а не упирались в один уровень, не зная об остальных.
Мы не просто пересказали SQLite — те же 8 рубежей воплощены в коде самого almazrobots.ru, на уровне адекватности для веб-приложения. 607+ тестов: юнит на всю чистую логику (auth-крипта, деньги, агрегации, csv), fault-injection на файловое хранилище, property-based фаззинг недоверенных парсеров, mutation-testing критичных модулей (score ~87% — тесты «с зубами»), корпус регресс-фикстур и релиз-чек-лист. Тесты — жёсткий гейт деплоя: красный тест не уезжает в прод.
Цена ошибки разная, а дисциплина одна: баг не закрыт, пока его вход не лёг в корпус; тестируй отказы, а не только happy path; разнообразие проверок важнее их количества; человек на вершине релиза.
SQLite — крайняя точка спектра. Вам столько не нужно — но знать, какие рубежи существуют, полезно всем. Рядом — такие же разборы «зачем и как» про работу с ИИ-агентами: каталог практик agentic coding.