Я выполняю управление версиями с помощью Git и модульное тестирование с помощью QUnit. Иногда я нахожу ошибку в своем программном обеспечении, которой не было в прошлой версии. Мне легко написать unit test специально для этой ошибки.
Учитывая, что unit test, могу ли я легко пройти через все мои прошлые коммиты и протестировать сборку с помощью этого unit test, чтобы я мог точно определить, какая фиксация вызвала поломку?
Используйте git bisect для этого, см. эту страницу.
Поскольку вы тестируете JavaScript, вам, вероятно, придется вручную запускать тесты и запускать git bisect good и git bisect bad по мере необходимости. Однако, если вы можете запустить unit test из командной строки, вы можете использовать git bisect run, чтобы Git выполнял тест несколько раз и автоматически отслеживал ошибку:
$ git bisect run my-script.sh
Эта чистая магия в первый раз, когда вы ее видите!: -)
Вы описали работу git bisect. В книге Git есть хороший учебник.
Существует также некоторая путаница в терминах вашего вопроса: когда тест используется для защиты от повторного введения ранее зафиксированных ошибок или для деления пополам багги-коммитов, это называется регрессионным тестом, а не unit test. Последний тест является чисто проверкой, если данная небольшая единица кода работает и находится под большими временными ограничениями (люди TDD запускают модульные тесты несколько десятков раз в день). Для большого проекта обычно у вас гораздо более длительные регрессионные тесты, чем модульные тесты, поэтому вы можете захотеть, чтобы категории были чистыми.
Git имеет команду делать именно то, что вы хотите, Git bisect
Найти по бинарному поиску изменение, введшее ошибку
В вашем случае вы хотите использовать его как git bisect run /path/to/script, который автоматически проверяет фиксации и выполняет проверку с каждой фиксацией, чтобы найти плохую фиксацию.
Обратите внимание, что script (my_script в приведенном выше примере) должен выйти с кодом 0, если текущий исходный код хорош, и выйти с кодом между 1 и 127 (включительно), кроме 125, если текущий исходный код плохо.
Любой другой код выхода прервет процесс bisect. Следует отметить, что программа, которая заканчивается через "exit (-1)", оставляет $? = 255, (см. Страницу руководства выхода (3)), поскольку значение прерывается "& 0377".
Специальный код выхода 125 должен использоваться, когда текущий исходный код не может быть протестирован. Если script выходит с этим кодом, текущая ревизия будет пропущена (см. git bisect skip выше). 125 был выбран в качестве наивысшей разумной ценности для использования для этой цели, поскольку 126 и 127 используются оболочками POSIX для сигнализации определенного состояния ошибки (127 для команды не найдена, 126 для команды найденной, но не исполняемой --- эти данные делают неважно, поскольку они являются нормальными ошибками в script, поскольку это касается "bisect run" ).
Итак, ваш script скомпилирует ваши источники, запустит ваш пакет unit test, а затем предоставит соответствующий код выхода. Примерный раздел из bisect manpage прекрасно описывает это (в том числе сломанные сборки, слияние исправлений и т.д.)
Да, это называется git bisect и впервые было введено в git.
Принцип:
c1;c1, которую вы знаете, не удается, назовите ее c2;git bisect start c2 c1.Вы даже можете ограничить bisect для подпапок, если знаете, где это не удается, и если у вас есть script, который может запускать тест не интерактивно, используйте git bisect run.