Минимальный тестовый набор
11 мая 2010
Поиск ошибок и их устранение — совершенно типичная задача. А на каждую типичную задачу существует своё решение. Сегодня об этом решении, применительно к вёрстке, написал Chris Coyier.
Заключается оно в составлении минимального тестового набора, то есть самого минимального набора условий, на котором можно воспроизвести проблему. После его составления, либо проблема полностью локализуется, либо находится ошибка в продукте, лежащем в основе вашего.
В первом случае либо решение очевидно, либо у нас имеется достаточный и, что самое главное, минимально необходимый набор кода, чтобы задать вопрос (и, что самое главное, получить ответ) на одном из тематических ресурсов. Поверьте, в случае, когда к вопросу прилагается объёмистый набор условий или кусок кода, 90% которого, скорее всего, к проблеме отношения не имеют, куда-то очень стремительно улетучивается желание помочь.
Второй случай также не так уж плох, так как у нас уже есть идеальный тестовый набор, который можно отослать разработчику. Такие «минимальные» вопросы чаще всего долго без ответа не остаются. В общем, разработчик оценит, поверьте.
Итак, как же получить минимальный тестовый набор:
1. Фиксируем данные
Если исходные данные постоянно меняются, проблема может проявляться через раз и поиск её сильно затрудняется. В этом случае сделать слепок данных и не менять его — отличная идея. Данными, в зависимости от того, что мы отлаживаем, могут выступать БД, PHP или JavaScript (при отладке вёрстки), HTTP-запрос или любые другие внешние, по отношению к отлаживаемому коду, факторы.
2. Изолируем
Делаем копию неработающего проекта или его части и уносим в отдельный проект. Так мы гарантированно ничего не поломаем в работающем проекте и ничто не поменяет исходных данных.
3. Сокращаем, сокращаем и ещё раз сокращаем
Выкидываем абсолютно всё, что не относится к делу. Если есть идея о том, какая часть работает не так — выкидываем всё остальное. Например, если у нас поплыла вёрстка блока авторизации на всех страницах — выносим её стили и разметку в отдельный файл.
В результате мы либо сразу получим более-менее минимальный набор, либо узнаем, что сама по себе проблема не проявляется и что-то на неё влияет.
Если никаких идей о том, где может быть ошибка не осталось — убираем 50% кода и проверяем оставшуюся половину. Например, для той же проблемы с вёрсткой, выключаем в браузере поддержку JavaScript. Если ошибка всё ещё на месте — она точно не в JavaScript и его можно из тестового набора убрать. После этого выкидываем 50% из оставшегося кода. Повторяем до того момента, пока не уберём всё, что можно убрать.
Данный подход используется множеством успешных компаний и проектов, таких как WebKit и GCC.
Комментарии RSS по email OK
Спасибо -- очень полезный материал.
я так понимаю, это не совсем перевод, а скорее пересказ, да?
Это своя заготовка, которая долго пылилась в черновиках и была переписана под сильным таким влиянием замечательно компактной статьи Chris Coyier. Получился почти пересказ :)