Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

return suite;

}

}

Пакет JUnit разработан по модульному принципу: к нему можно добавлять сколько угодно тестов, и каждый из них может, в свою очередь, являться пакетом. В дополнение к этому для управления процедурой тестирования вы можете выбрать графический или текстовый интерфейс.

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

Это означает, что зачастую приходится тестировать фрагмент программного обеспечения сразу после его развертывания – с реальными данными, текущими в его жилах. В отличие от печатной платы или чипа, в программном обеспечении нет тестовых контактов, но можно по-разному взглянуть на внутреннее состояние модуля, не прибегая к помощи отладчика (в производственных условиях его применение либо неудобно, либо просто невозможно).

Одним из таких механизмов являются файлы журналов. Сообщения в журналах должны записываться в обычном последовательном формате; возможно, вы захотите провести их синтаксический анализ в автоматическом режиме дня определения времени обработки или логических путей, по которым двигалась программа. Диагностические процедуры, составленные небрежно или в несовместимом формате, вызывают тошноту – их трудно читать и непрактично анализировать.

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

Для более крупных программ, работающих на серверах, существует изящная технология, заключающаяся в том, что для слежения за ходом работы используется встроенный web-сервер. Можно привязать web-браузер к HTTP-порту приложения

(который обычно имеет нестандартный номер типа 8080) и увидеть внутреннее состояние, журналы и даже нечто вроде панели управления отладкой. Реализация этого может показаться сложным делом, что не соответствует действительности это. Бесплатно внедряемые web-серверы с протоколом HTTP реализованы на различных современных языках программирования. Поиск можно начать с сайта [URL 58].

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

Несмотря на репутацию хакеров, члены сообщества Perl являются стойкими приверженцами регрессионного и модульного тестирования. Стандартная процедура инсталляции модуля в Perl поддерживает регрессионное тестирование с помощью команды

% make test

В этом отношении сам по себе Perl не является чем-то сверхъестественным. Perl облегчает сопоставление и анализ результатов тестирования для обеспечения соответствия, но его большое преимущество состоит в том, что он является стандартом – тестирование проводится в конкретном месте и имеет предсказуемый результат. Тестирование в большей степени является вопросом культуры, а не техники, независимо от используемого вами языка.

Подсказка 49: Тестируйте ваши программы, в противном случае это сделают ваши пользователи

• Мой исходный текст съел кот Мурзик

• Ортогональность

• Проектирование по контракту

• Реорганизация

• Безжалостное тестирование

41. Спроектируйте тестовый шаблон для интерфейса блендера для коктейлей, описанного в ответе к упражнению 17 (см. Приложение В). Напишите сценарий оболочки, который осуществит регрессионное тестирование блендерa. Необходимо проверить основные функциональные возможности, ошибки и граничные условия, а также любые обязательства по контракту. Какие ограничения налагаются на изменение скорости вращения ротора блендера? Соблюдаются ли они?

Никто не может отрицать – создавать приложения становится все сложнее и сложнее. В частности, пользовательские интерфейсы становятся все более утонченными. Двадцать лет назад приложение среднего масштаба обошлось бы интерфейсом «стеклянного телетайпа» (а может быть, интерфейса не было бы и вовсе). Асинхронные терминалы обеспечивали интерактивное отображение символов, а устройства ввода (наподобие вездесущей IBM 3270) позволяли набирать целую экранную страницу перед нажатием клавиши SEND. Теперь пользователи требуют графический интерфейс с контекстно-зависимой справкой, средствами типа «вырезать и вставить», «перетащить и отпустить», средством OLE, много- или однодокументным интерфейсом. Пользователям потребна интеграция с web-браузером и поддержка архитектуры с тонким клиентом.