Семь open-source инструментов для проверки ИИ-кода перед продакшеном
Семь проектов с GitHub, от мутационного тестирования до нагрузочных тестов, которые проверяют качество тестов, утечки секретов, зависимости, доступность и скорость приложений, написанных ИИ.
Ваш ассистент для кода сообщает, что работа готова, тесты зелёные, а приложение работает в превью. Кажется, что дело сделано. Обычно это не так.
Зелёный прогон тестов доказывает только то, что тесты прошли. Упали бы эти тесты на сломанной реализации — отдельный вопрос. Как и несколько других: не проскользнул ли в коммит какой-нибудь ключ, нет ли в подтянутых пакетах известных дыр и что будет, если приложение одновременно откроют пятьдесят человек? Сам ассистент на такие вопросы редко отвечает.
Эти пробелы закрывают семь open-source инструментов, и каждый смотрит со своей стороны: надёжность тестов, утёкшие секреты, уязвимые зависимости, паттерны в коде, мёртвый код, доступность и нагрузка. Несколько из них нацелены на JavaScript и TypeScript, поэтому особенно хорошо подходят для веб-приложений, созданных ИИ. Прогоните их до того, как что-либо попадёт в продакшен.
StrykerJS: а ваши тесты вообще кусаются?
StrykerJS — фреймворк мутационного тестирования для JavaScript и TypeScript. Он вносит в исходники мелкие намеренные изменения, например переворачивает сравнение или удаляет оператор, и каждый раз заново запускает набор тестов. Если после изменения все тесты по-прежнему проходят, у набора есть слепое пятно. Проценты покрытия этого не покажут, потому что строка может выполняться, но так ни разу и не проверяться.
На небольшом проекте его можно попробовать сразу:
pnpm add --save-dev @stryker-mutator/core
# Only for small projects:
npx stryker run
Без конфигурации он использует разумные значения по умолчанию: запускает npm test как команду тестов и ищет код для мутаций в lib и src.
Gitleaks: ловите секреты заранее
Gitleaks сканирует файлы и историю Git в поисках учётных данных вроде API-ключей и токенов. Его можно запускать вручную или встроить в автоматический пайплайн, и тогда утёкший ключ остановят до того, как он разойдётся по клонам и форкам. Сгенерированный код — частый источник этой проблемы, ведь модель охотно вставляет ключ-заглушку, который потом оказывается настоящим.
Чтобы скачать и собрать его:
git clone https://github.com/gitleaks/gitleaks.git
cd gitleaks
make build
OSV-Scanner: знайте, от чего вы зависите
OSV-Scanner сверяет пакеты из ваших lock-файлов с базой уязвимостей OSV. Он сообщает, для каких именно ваших версий опубликованы предупреждения, и даёт конкретную картину риска, который приносят зависимости. Ассистенты часто добавляют библиотеки не задумываясь, так что эта проверка быстро окупается.
Собрать его можно с помощью Go:
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
Semgrep: статический анализ по правилам
Semgrep — быстрый open-source статический анализатор. Он ищет паттерны в коде, чтобы находить баги, отмечать небезопасные конструкции и следить за соблюдением соглашений команды. Он понимает больше тридцати языков и работает в редакторе, как pre-commit хук или внутри задачи CI/CD.
Устанавливается через pip:
python3 -m pip install semgrep
Knip: удалите то, чем никто не пользуется
Knip находит в проектах на JavaScript и TypeScript файлы, зависимости и экспорты, на которые ничто не ссылается. В сгенерированном коде остатки копятся быстро: заброшенные хелперы, пакеты, которые добавили и так и не импортировали. Их чистка уменьшает нагрузку на сопровождение и делает репозиторий читабельнее по мере его роста.
axe-core: проверки доступности
axe-core — движок для тестирования доступности веб-страниц и других интерфейсов на HTML. Он быстрый и лёгкий и подключается к любой тестовой связке, которая у вас уже есть, так что проверки доступности могут стоять рядом с обычными функциональными. Ассистенты склонны выдавать разметку, которая выглядит правильно, но в ней не хватает меток, ролей и контраста, и именно так вы это заметите.
k6: как оно ведёт себя под нагрузкой?
k6 — инструмент нагрузочного тестирования. Вы описываете сценарии в коде, измеряете время ответа и долю ошибок и задаёте пороги, которые автоматически валят прогон, если производительность проседает. Небольшой пример:
import http from "k6/http";
import { check, sleep } from "k6";
// Test configuration
export const options = {
thresholds: {
// Assert that 99% of requests finish within 3000ms.
http_req_duration: ["p(99) < 3000"],
},
// Ramp the number of virtual users up and down
stages: [
{ duration: "30s", target: 15 },
{ duration: "1m", target: 15 },
{ duration: "20s", target: 0 },
],
};
// Simulated user behavior
export default function () {
let res = http.get("https://quickpizza.grafana.com");
// Validate response status
check(res, { "status was 200": (r) => r.status == 200 });
sleep(1);
}
Скрипт имитирует десять виртуальных пользователей в течение тридцати секунд, и каждый делает паузу в секунду между запросами. Его пороги требуют, чтобы 95-й перцентиль времени ответа оставался ниже 500 мс, а неудачных запросов было меньше 1%.
Сохраните файл как test.js, установите k6 и запустите его командой k6 run test.js.
Собираем всё вместе
Ни один из этих инструментов не доказывает, что ваше приложение корректно, и не должен. Вместе они закрывают вопросы, которые пропускает успешное демо. Начните с Gitleaks и OSV-Scanner: они занимают минуты и ловят самые дорогие ошибки. Потом добавьте Stryker и Semgrep для проверки самого кода, Knip для его чистки, axe-core для доступности и k6 для трафика. Если в ваш собственный чек-лист просится другой open-source инструмент, добавьте его. Цель каждый раз одна: доверяйте результату только после того, как что-то попыталось его сломать.