Поиск и исправление ваших ошибок

9.5.2. Очистка после поиска

Когда вы закончили работать с hg bisect, вы можете использовать hg bisect --reset чтобы сбросить информацию, которую он использовал для проведения вашего поиска. Команда не использует много места, поэтому не страшно, если вы забыли запустить эту команду. Тем не менее, hg bisect не позволит вам начать новый поиск в этом хранилище, пока вы не cделаете hg bisect --reset.

$ hg bisect --reset

9.6. Советы для эффективного поиска ошибок

9.6.1. Давайте согласованный ввод

Команда hg bisect требует, чтобы вы правильно сообщали о результатах каждого теста, который вы выполняете. Если вы скажете, что это испытание не прошло, когда это действительно удалось, иногда можно обнаружить несоответствие. Если удалось определить несоответствия в Ваших отчетах, Mercurial сообщит Вам, что некоторая ревизия и хорошая и плохая. Однако, он не может делать это всегда, чаще он укажет на неправильную ревизию в качестве источника ошибки.

9.6.2. Автоматизируйте как можно больше

Когда я начал использовать команду hg bisect, я пытался несколько раз выполнить свои тесты вручную, в командной строке. С таким подходом я убил по крайней мере, первую половину дня. После нескольких попыток, я обнаружил, что я делал много ошибок, из-за которых мне приходилось перезапускать поиск несколько раз, чтобы наконец, получить правильные результаты.

Мои первоначальные проблемы с управлением командой hg bisect вручную происходили даже с простым поиском по малым репозиториям, а если проблема, которую вы ищете более тонкая, или количество тестов, которые hg bisect необходимо выполнить возрастает, вероятность ошибки оператора испортить поиск гораздо выше. Как только я начал автоматизировать мои тесты, я получал лучше результаты.

Ключ к автоматизированному тестированию является двойным:

•всегда проверяйте одни и те же симптомы, и

•всегда передавайте согласованный ввод для команды hg bisect

В моем учебном примере приведенном выше, команда grep тестирует симптом, и условие if принимает результат этой проверки и гарантирует, что мы всегда передаём тот же самое на вход команды hg bisect. Функция mytest связывается с этими тегами воспроизводимым образом, чтобы каждый тест являлся однородным и последовательным.

9.6.3. Проверка ваших результатов

Потому что вывод поиска hg bisect хороша лишь на входных данных которые вы ему передаёте, не принимайте этот отчёт с набором ревизий, как абсолютную истину. Самым простым способом для перекрестной проверки его отчёта, будет запуск вручную тестов на каждой из следующих ревизий:

•Ревизия, которая помечена первой плохой ревизией. Ваш тест должен сообщать о ней что она по прежнему плохая.

•Родителей, этой ревизии (каждого из родителей, если это слияние). Ваш тест должен сообщить об этих ревизиях как хороших.

•Потомка этой ревизии. Ваш тест должен сообщить об этой ревизии как о плохой.

108

Поиск и исправление ваших ошибок

9.6.4. Остерегайтесь интерференции ошибок

Вполне возможно, что ваш поиск одной ошибки может быть нарушен присутствием другой. Например, предположим, что в вашей программе ошибка в ревизии 100, и она работала правильно на ревизии 50. Кто-то неизвестный вам вставил различные ошибки в ревизию 60, и исправил их в ревизии 80. Это может исказить ваш результат одним из нескольких способов.

Вполне возможно, что эта совершенно другая ошибка «маскирует» вашу, и есть шанс, что эта ошибка проявит себя перед вашей ошибкой. Если вы не можете избежать этой другой ошибки (например, она не даёт вашему проекту собраться), и поэтому нельзя сказать есть ли ваша ошибка в конкретной ревизии, команда hg bisect не может помочь вам непосредственно. Вместо этого, вы можете пометить непроверяемую ревизию, запустив hg bisect --skip.

Другая проблема может возникнуть, если тест на наличие ошибка не является достаточно точным. Если вы проверяете условие «моя программа падает», то и ваша ошибка и сбой связанный с ошибкой, маскирующей вашу, будет выглядеть одинаково, и введёт в заблуждение hg bisect.

Еще одна ситуация, в которой полезно использовать hg bisect --skip, если вы не можете проверить ревизию, так как ваш проект был в сломан и, следовательно, нетестируем в той ревизии, возможно, что кто-то уже проверил в изменениях, которые приводили к провалу сборки проекта.

9.6.5. Опора вашего ленивого поиска

Выбрать первые «хорошую» и «плохую» ревизии, которые означают конечные точки поиска, зачастую нелегко, но тем не менее это приводит к небольшой дискуссии. С точки зрения hg bisect, «новейшая» ревизия условно обозначается как «плохая», а самая старшая ревизия как «хорошая».

Если вы не помните, когда была подходящая «хорошая» ревизия, о которой вы можете сказать hg bisect, вы можете сделать хуже, чем при тестировании ревизий наугад. Просто помните, для ликвидации ошибок, важны моменты когда ошибка появится не может(возможно, потому что программы с ошибкой ещё не было), и те моменты, когда одна проблема маскирует другую (как я говорил выше).

Даже если вы в конечном итоге «ранняя» ревизия будет за тысячу ревизий или месяцев истории, вы увидите добавление только нескольких тестов hg bisect, которые необходимо выполнить, благодаря логарифмическому поведению.

109