Посмертное юнит-тестирование

Question

Я делаю контроль версий с помощью Git, а модульное тестирование - с помощью QUnit. Иногда в моем программном обеспечении обнаруживается ошибка, которой не было в прошлой версии. Мне легко написать модульный тест специально для этой ошибки.

Учитывая этот модульный тест, могу ли я легко пройти все мои прошлые коммиты и протестировать сборку с этим модульным тестом, чтобы я мог точно определить, какой коммит вызвал сбой?

Answer 1

Вы описали работу git bisect. В Git Book есть хороший учебник .

Существует также некоторая путаница в терминах вашего вопроса: когда тест используется для предотвращения повторного введения ранее исправленных ошибок или для деления пополам коммитов с ошибками, он называется регрессионным тестом , не модульный тест . Последний тест является чисто тестированием, если данный небольшой блок кода работает и испытывает серьезные ограничения по времени (сотрудники TDD проводят модульные тесты несколько десятков раз в день). В большом проекте у вас обычно гораздо более длительные регрессионные тесты, чем у модульных, поэтому вы можете захотеть получить чистые категории.

Answer 2

Используйте git bisect для этого, пожалуйста, смотрите эту страницу .

Поскольку вы тестируете JavaScript, вам, вероятно, придется запускать тесты вручную и запускать git bisect good иgit bisect bad в зависимости от ситуации.Однако, если вы можете запустить свой модульный тест из командной строки, то вы можете использовать git bisect run, чтобы Git повторно выполнил тест и отследил ошибочный коммит автоматически:

$ git bisect run my-script.sh

Это первое волшебствораз вы видите это!: -)

Answer 3

Git имеет команду, чтобы сделать именно то, что вы хотите, git bisect

Найти с помощью бинарного поиска изменения, которые привели к ошибке

В вашем случае вы хотите использовать его как git bisect run /path/to/script, который будет автоматически проверять коммиты и выполнять проверку с каждым коммитом, чтобы найти bad commit.

Обратите внимание, что скрипт(my_script в приведенном выше примере) должен завершиться с кодом 0, если текущий исходный код исправен, и завершиться с кодом от 1 до 127 (включительно), кроме 125, если текущий исходный код неверен.

Любой другой код завершения прервет процесс деления пополам.Следует отметить, что программа, которая завершается через «exit (-1)», оставляет $?= 255, (см. Страницу руководства выхода (3)), поскольку значение обрезается с помощью «& 0377».

Специальный код выхода 125 следует использовать, когда текущий исходный код не может быть протестирован.Если скрипт завершает работу с этим кодом, текущая ревизия будет пропущена (см. Git bisect skip выше).125 было выбрано в качестве наивысшего разумного значения для использования для этой цели, поскольку 126 и 127 используются оболочками POSIX для сигнализации о конкретном состоянии ошибки (127 - для команды, не найденной, 126 - для команды, найденной, но не исполняемой - эти детали делаютне имеет значения, так как они являются обычными ошибками в скрипте, поскольку речь идет о «bisect run»).

Итак, ваш скрипт скомпилирует ваши исходные коды, запустит ваш пакет модульных тестов и затем выдастсоответствующий код выхода.Раздел примера из bisect manpage хорошо описывает это (включая неработающие сборки, слияния коммитов исправлений и т. Д.)

Answer 4

Да, это называется git bisect и впервые было введено в git.

Принцип:

• захватить коммит в прошлом, где вы знаете, что он работал, давайте назовемэто c1;
• захватить коммит после c1, который вы знаете, терпит неудачу, назовите его c2;
• git bisect start c2 c1.

Вы можете дажеограничьте бисект подпутями, если вы знаете, где он терпит неудачу, и , если у вас есть сценарий, который может выполнять тест не в интерактивном режиме, используйте git bisect run.