Бич блочного тестирования: интерфейсы пользователя
Я твердо убежден, что разработчики Microsoft получают туннельный синдром запястья не от того, что им приходится вводить исходный код с клавиатуры, а от многократного нажатия одних и тех же комбинаций клавиш при тестировании своих приложений. После 5000-го нажатия <Alt>+<F>, <О> запястья зажаты плотнее, чем арматура в бетоне. Без инструмента автоматизации задач, имеющих доступ к различным свойствам ваших приложений, вообще приходится следовать некоторому сценарию, чтобы гарантировать выполнение блочного тестирования в достаточном объеме. Тестирование со сценариями — чрезвычайно скучная процедура, которая оставляет множество лазеек для человеческих ошибок.
Автоматизация блочных тестов означает уменьшение количества ввода с клавиатуры и уменьшение затрат времени на проверку состояния кода. К сожалению, приложение Recorder, которое обычно поставлялось с Windows 3.x, не включается в состав 32-разрядных операционных систем. Recorder обеспечивал запись действий пользователя (с мышью и клавиатурой) и последующее их воспроизведение, как если бы они были событиями физической мыши и клавиатуры (правда на его возможности воспроизведения перемещений мыши были наложены очень неудобные ограничения). Сейчас доступны продукты независимых поставщиков, предназначенные для автоматизации приложений и других работ (например, полной проверки каждого пиксела при сравнении экранов, поддержки служебных баз данных, связанных с тестированием, и т. д.), но требовалось создать нечто более удобное и предназначенное специально для инженеров-разработчиков. Так родилась идея этого приложения.
Когда я решил создать автоматизированную утилиту, то потратил некоторое время на уточнение того, что же можно ожидать от такого инструмента. Прежде всего, я подумал о разработке утилиты, похожей на старое приложение Recorder. В далекие времена Windows 3.x имелся полный набор REC-файлов для проведения тестирования. Однако у этого приложения был большой недостаток — оно не могло выполнять условные тесты.
Если во время тестирования приложение сообщало об ошибке, то Recorder шел по самому легкому пути — он просто воспроизводил зарегистрированные нажатия клавиш и щелчки мыши, полностью забывая о бедствии приложения. Однажды я стер половину операционной системы, потому что тестировал расширение WINFILE.EXE, и когда в нем возникли ошибки, Recorder выполнил последовательность удаления файлов для всего каталога
\System. Новый автоматизированный инструмент определенно должен поддерживать конструкцию
if. . .then. . .else.
Чтобы включить в тесты условные конструкции, необходимо было использовать некоторый вид языка. Разработка собственного языка тестирования была бы увлекательным интеллектуальным упражнением, но вскоре я решил, что больше заинтересован в написании полезного инструмента отладки, чем в проектировании языка и возне с компиляторами YACC и FLEX. Потребовалось всего две секунды, чтобы понять, что надо написать Tester как СОМ-объект — таким образом, разработчики смогут использовать эту утилиту, а для написания тестов выбрать любой язык; я при этом мог сконцентрироваться на программировании свойств регрессивного тестирования (regression-testing) утилиты вместо проектирования нового языка. В качестве языков тестирования были выбраны языки сценариев типа Microsoft Visual Basic Scripting Edition (VBScript) и Java Script (JScript), потому что сценарии тестирования не требуют компиляции. Однако различные реализации машин сценариев Scripting Host (WSH) имеют несколько ограничений, которые будут рассмотрены чуть позже. Пока же поговорим о требованиях, которые привели меня к созданию утилиты Tester.
