Главная / Статьи / Семь open-source инструментов для проверки ИИ-кода перед продакшеном

Семь open-source инструментов для проверки ИИ-кода перед продакшеном

Семь проектов с GitHub, от мутационного тестирования до нагрузочных тестов, которые проверяют качество тестов, утечки секретов, зависимости, доступность и скорость приложений, написанных ИИ.

941 слов

Ваш ассистент для кода сообщает, что работа готова, тесты зелёные, а приложение работает в превью. Кажется, что дело сделано. Обычно это не так.

Зелёный прогон тестов доказывает только то, что тесты прошли. Упали бы эти тесты на сломанной реализации — отдельный вопрос. Как и несколько других: не проскользнул ли в коммит какой-нибудь ключ, нет ли в подтянутых пакетах известных дыр и что будет, если приложение одновременно откроют пятьдесят человек? Сам ассистент на такие вопросы редко отвечает.

Эти пробелы закрывают семь 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 инструмент, добавьте его. Цель каждый раз одна: доверяйте результату только после того, как что-то попыталось его сломать.