Автоматическое обнаружение ошибок с помощью git bisect и mvn test

Знаете ли вы чувство, когда вы обнаружили ошибку в функционале, который работал пару недель (или версий) назад? Жаль, что у нас не было никаких автоматических тестов, и то, что раньше было хорошо, теперь сломано. Давайте возьмем этот простой репозиторий в качестве примера:

Сначала напишите тест

Мы заметили, что некоторые конкретные функции были в порядке в версии 1.0, но не работает в 1.1. Что мы делаем в первую очередь? Конечно, напишите тестовый пример, чтобы убедиться, что эта ошибка, однажды исправленная, никогда не вернется! Написание (провал) теста для каждой найденной ошибки имеет много преимуществ:

1. Он документирует ошибки и доказывает, что они были исправлены
2. Неочевидные обходные пути и решения не будут удалены («почему он здесь проверяет null ?! Это невозможно, давайте упростим это») случайно
3. Вы постепенно улучшаете общее покрытие кода, даже в устаревшей кодовой базе.

Итак, у вас есть провальный тестовый случай. Но даже с изолированным тестом вы не можете достоверно выяснить, что не так. Если бы только мы могли найти коммит, который сломал этот тест — предполагая, что коммиты маленькие и сфокусированные. Но если мы зафиксируем наш тест прямо сейчас и включим одну из старых версий для его запуска — его еще нет. В конце концов, тест сделал то, что нужно для кодовой базы только сейчас, если бы он был там с первой ревизии, у нас не было бы проблемы вообще:

Интерактивный ребазинг

Может быть, вместо того, чтобы делать тест после версии 1.1 (где мы знаем, что он сломан), нам следует сделать патч или спрятать этот тест? Таким образом, мы могли бы пройти через все ревизии между 1.0 и 1.1, распаковать или применить патч с test и запустить его. Надеюсь, вы согласны, что это далеко не идеально. Первый трюк заключается в использовании интерактивной перебазировки для того, чтобы сдвинуть коммит с неудачным тестом в прошлое. Однако мы не хотим перебазировать master ветку, поэтому мы делаем временную копию и перебазируем ее:

Интерактивная перебазировка попросит нас переставить коммиты перед продолжением, просто переместите коммит с тестовым набором из последней в первую позицию:

Теперь наш репозиторий должен выглядеть примерно так:

мерзавец

Самое главное, наш тестовый пример теперь внедряется сразу после версии 1.0 (известно, что это хорошо). Все, что нам нужно сделать, это проверить все ревизии одну за другой и запустить этот тест. СТОП! Если вы сообразительны (или ленивы), вы начнете с коммита прямо в середине, а если он сломан, вы продолжите с первой половиной таким же образом — или возьмите вторую половину иначе. Это как бинарный поиск. Однако отслеживать, какой коммит в последний раз считался хорошим и плохим, а также вручную проверять ревизию в середине, довольно громоздко. К счастью, git может сделать это для нас с помощью команды git bisect . В принципе после начала деления пополам мы указываем последний известный хороший и первый известный плохой коммит. Git проверит ревизию между ними и спросит нас, хорошо это или плохо, продолжая до тех пор, пока мы точно не выясним, какой именно код зафиксирован. В нашем случае мы просто запускаем mvn test и действуем в зависимости от его результата:

Посмотрите, как мы итеративно называем git good / bad выполняя наш тестовый пример между ними? Также обратите внимание, как быстро количество коммитов для тестирования сокращается. Вы можете подумать, что это аккуратно и быстро (логарифмическое время!), Но на самом деле мы можем идти намного быстрее. git bisect есть скрытый драгоценный камень, называемый режимом run . Вместо того, чтобы полагаться на ручной ответ пользователя после каждой итерации, мы можем предоставить скрипт, который сообщает, является ли данная ревизия хорошей или плохой. По соглашению, если этот скрипт завершает работу с кодом 0, это означает успех, тогда как любой другой код завершения сигнализирует об ошибке. К счастью, скрипт mvn следует этому соглашению, поэтому мы можем просто выполнить git bisect mvn test -Dcom.nurkiewicz.BugTest , расслабиться и расслабиться:

Программа выше не является интерактивной и полностью автоматизирована. git, после нескольких итераций, указывает, какой именно коммит был первым, кто нарушил тест. Мы можем запустить все тесты, но в этом нет никакого смысла, поскольку мы знаем, что только этот тест не пройден. Конечно, вы можете использовать любую другую команду, а не mvn . Вы даже можете написать какой-нибудь простой скрипт на любом языке JVM по вашему выбору (используйте System.exit () ). git bisect в сочетании с интерактивным перебазированием — замечательные инструменты для поиска регрессий и ошибок. Также они способствуют автоматизированному тестированию и автоматизации в целом.