Успешный запуск нового теста сам по себе не показывает, что тест замечает внесённое изменение: он мог бы пройти и на прежней версии программы. Trustbut предназначен для такой проверки. По описанию разработчика, инструмент повторно запускает тесты в чистой копии проекта и проверяет новые или изменённые тесты на коде до правки. Это свидетельство о поведении тестов в конкретном запуске, а не доказательство корректности всей реализации.
Какую задачу решает trustbut
Trustbut — локальная утилита командной строки, которая, согласно README проекта, формирует receipt для изменения кода, написанного человеком или AI-агентом. Её задача — проверить, меняется ли поведение нового или изменённого теста при сравнении версии кода с правкой и без неё. Описание механизма и демонстрационный receipt опубликованы в README проекта.
Практический вопрос узкий: не проходит ли новый тест на версии кода до изменения, но проходит на версии с изменением? Если он проходит и на старой версии, его успешное выполнение не свидетельствует, что тест проверяет именно эту правку. Такой критерий помогает выявить слабое свидетельство, но не оценивает полноту набора тестов и не устанавливает, соответствует ли программа требованиям.
Как устроена проверка
README описывает два шага: trustbut повторно запускает тесты в чистой копии проекта, а каждый новый или изменённый тест запускает на версии кода до правки. По логике разработчика, тест, который проходит и на старом коде, не подтверждает изменение этим сравнением.
Инструмент также, по заявлению автора, отмечает пропущенные тесты, удалённые утверждения и отключённые проверки типов. Эти предупреждения помогают найти места для ревью, но сами по себе не устанавливают причину изменения или ошибочность правки. Их нужно соотносить с diff и тем, что именно должен проверять тест.
Метод отвечает на ограниченный вопрос о поведении выбранных тестов в двух версиях кода. Он не заменяет ревью, не доказывает отсутствие ошибок и не показывает, покрывают ли тесты все важные сценарии. Независимой оценки того, насколько надёжно trustbut выявляет слабые тесты, нет.
Как читать PASS, WARN и FAIL
Разработчик описывает три итоговых статуса: PASS, WARN и FAIL. Это вердикты по конкретному запуску, а не универсальная сертификация изменения. Для практического решения важны результаты отдельных тестов и предупреждения, на которых основан статус.
Если новый тест не проходит на старой версии и проходит на новой, это свидетельство, что его поведение связано с правкой. Но оно не доказывает, что ожидание в тесте сформулировано верно или что реализация корректна. Если тест проходит на обеих версиях, он не показывает различия, связанные с изменением, хотя может проверять другое поведение.
README описывает и сценарий подключения к агенту: receipt со статусом FAIL может останавливать завершение работы, пока агент продолжает исправления. Это заявленная возможность интеграции, а не доказательство того, что такой цикл всегда приводит к правильному результату. Статус разумно использовать как повод изучить конкретные данные, а не как автоматическое решение о слиянии.
Что показывает пример receipt
В README приведён демонстрационный запуск npx trustbut verify со статусом WARN. В примере указаны 41 успешный тест, 0 неуспешных и 1 пропущенный. Один новый или изменённый тест обозначен как подтверждающий изменение, а ещё один проходит и без него. Это пример формата вывода, а не редакционный тест или независимое измерение эффективности.
Среди находок примера — пропущенный тест и приведение типа к any. Пропущенная проверка не была выполнена; приведение типа может ослабить контроль типов в конкретном месте. Ни одна из этих находок сама по себе не доказывает ошибочность изменения. Receipt совмещает счётчики тестов, оценку новых проверок и предупреждения, которые требуют отдельной интерпретации.
Автор README упоминает собственное измерение на 201 pull request, но не приводит в доступном описании подробностей метода и результатов. Поэтому это упоминание не позволяет судить о точности, частоте ложных срабатываний или практической эффективности инструмента. Независимой оценки этих показателей нет.
Поддержка и применение на практике
README перечисляет языки и тестовые раннеры, с которыми, по заявлению разработчика, совместим инструмент. Для Kotlin отдельно указано, что сквозной тест на Kotlin ещё предстоит; список совместимости и отметки о проверках приводит сам автор. Их нельзя считать независимой проверкой поддержки для всех конфигураций.
Практический сценарий — получить receipt после изменения, особенно если код или тесты написал агент, и посмотреть: какие тесты прошли в чистой копии, какие новые проверки не проходят на старой версии и какие предупреждения требуют ревью. Прохождение теста до и после правки не подтверждает именно эту правку по описанному критерию. Провал на старом коде и успех на новом — аргумент в пользу связи теста с изменением, но не доказательство правильности реализации.
Итог trustbut позволяет судить о наблюдаемом поведении тестов и предупреждениях в конкретном запуске. Он не устанавливает полную корректность кода и достаточность тестового покрытия. Receipt полезен как дополнительный материал к ревью, но не заменяет проверку того, что именно тест должен доказывать.
