<rmcreative>

RSS

Минимальный тестовый набор

11 мая 2010

Поиск ошибок и их устранение — совершенно типичная задача. А на каждую типичную задачу существует своё решение. Сегодня об этом решении, применительно к вёрстке, написал Chris Coyier.

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

В первом случае либо решение очевидно, либо у нас имеется достаточный и, что самое главное, минимально необходимый набор кода, чтобы задать вопрос (и, что самое главное, получить ответ) на одном из тематических ресурсов. Поверьте, в случае, когда к вопросу прилагается объёмистый набор условий или кусок кода, 90% которого, скорее всего, к проблеме отношения не имеют, куда-то очень стремительно улетучивается желание помочь.

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

Итак, как же получить минимальный тестовый набор:

1. Фиксируем данные

Если исходные данные постоянно меняются, проблема может проявляться через раз и поиск её сильно затрудняется. В этом случае сделать слепок данных и не менять его — отличная идея. Данными, в зависимости от того, что мы отлаживаем, могут выступать БД, PHP или JavaScript (при отладке вёрстки), HTTP-запрос или любые другие внешние, по отношению к отлаживаемому коду, факторы.

2. Изолируем

Делаем копию неработающего проекта или его части и уносим в отдельный проект. Так мы гарантированно ничего не поломаем в работающем проекте и ничто не поменяет исходных данных.

3. Сокращаем, сокращаем и ещё раз сокращаем

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

В результате мы либо сразу получим более-менее минимальный набор, либо узнаем, что сама по себе проблема не проявляется и что-то на неё влияет.

Если никаких идей о том, где может быть ошибка не осталось — убираем 50% кода и проверяем оставшуюся половину. Например, для той же проблемы с вёрсткой, выключаем в браузере поддержку JavaScript. Если ошибка всё ещё на месте — она точно не в JavaScript и его можно из тестового набора убрать. После этого выкидываем 50% из оставшегося кода. Повторяем до того момента, пока не уберём всё, что можно убрать.

Данный подход используется множеством успешных компаний и проектов, таких как WebKit и GCC.

Комментарии RSS

  1. №2526
    Чистяков Денис
    Чистяков Денис 12 мая 2010 г., 9:43:47

    Спасибо -- очень полезный материал.

    я так понимаю, это не совсем перевод, а скорее пересказ, да?

  2. №2527
    Sam
    Sam 12 мая 2010 г., 13:43:16

    Это своя заготовка, которая долго пылилась в черновиках и была переписана под сильным таким влиянием замечательно компактной статьи Chris Coyier. Получился почти пересказ :)

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.