Тестирование модулей

We use cookies. Read the Privacy and Cookie Policy

Тестирование модулей

Тестирование модулей (unit testing) представляет собой процесс тестирования отдельных частей независимо от самой программы.

Одним из новых методов разработки программного обеспечения, который появился уже при написании этой книги, является экстремальное программирование (extreme programming)[3]. Этот метод состоит в целом наборе рекомендаций. Некоторые рекомендации достаточно спорны, но, по крайней мере, одна из них имеет смысл: пишите тест тогда, когда вы пишете метод класса. Если метод требует не одного теста, разработайте несколько тестов. Такой порядок обладает двумя преимуществами: во-первых, код вам знаком - вы только что его написали, и, во-вторых, в дальнейшем разработанный тест может быть включен в тестовый набор и применяться для тестирования приложения после внесения в него изменений. Таким образом, вы можете быть уверены, что изменения не повлекли за собой возникновение ошибок.

Эта рекомендация, вероятно, не соответствует тому, как большинство из нас тестирует программы. Мы, как правило, пишем блоки кода, а затем, два-три месяца спустя, пытаемся объединить их в одно целое с множеством других блоков и только потом приступаем к тестированию всей системы.

Тестирование модулей требует наличия специального средства, которое помогало бы собирать тесты, поддерживать их актуальность и периодически, в автоматическом режиме, запускать их с целью проверки правильности кода. К счастью, существует одна библиотека с открытым исходным кодом, которую можно использовать свободно, - Duhit. Она представляет собой порт для Delphi инструментальных средств тестирования Java-модулей, частично написанный автором книги "Extreme Programming Explained" Кентом Беком (Kent Beck). (Dunit можно использовать, только начиная с версии Delphi 3.)

Dunit представляет собой средство тестирования, или тестовый каркас, реализованный на Delphi. Используя его, программист пишет отдельные тесты, предназначенные для проверки своего кода. Тесты могут быть совсем простыми (например, в тесте может создаваться объект, проверяться значения заданных по умолчанию свойств, после чего объект удаляется), но в общем случае они должны быть предназначены для выполнения всего кода класса или модуля. (Чтобы убедиться, что выполняются все строки кода, можно воспользоваться анализатором покрытия.) Сам тестовый каркас предоставляет пользовательский интерфейс, который позволяет программисту выбрать один или несколько тестов и запустить их. После выполнения теста или тестов программист может просмотреть результаты: успешное выполнение или ошибка (Dunit при выводе результатов использует различные цвета, благодаря чему результат выполнения теста можно оценить с первого взгляда.) Конечно, по истечении некоторого времени тест может оказаться неактуальным, поскольку, например, класс настолько изменился, что выполнение существующего теста не позволяет определить правильность кода. В таком случае тест потребуется написать заново.

----

Правило № 6. Для организации набора тестов для проверки модулей воспользуйтесь тестовым каркасом. При изменении кода выполните тесты повторно.

----

Если у вас есть Dunit для определенного класса или модуля, его можно использовать для регрессионного тестирования (regression testing). Регрессионное тестирование представляет собой тестирование всего класса или модуля после внесения изменений в этот класс или модуль. Часто поиск и устранение одной ошибки приводит к возникновению другой ошибки.

Рассмотрим пример. В библиотеке TurboPower Internet Professional (библиотека Delphi для реализации таких протоколов Internet, как FTP, HTTP и т.д.) имеется функция, которая разбивает URL на различные части. URL-адрес может указывать на Web-сайт или на FTP- сайт, это может быть относительный путь (например, путь к графическому изображению на Web-странице, может указываться относительно папки, в которой находится основная Web-страница), или MAILTO-адрес, или просто файл на жестком диске. Формат URL-адреса достаточно сложен. Его можно видеть в адресной сроке Web-браузера. Синтаксический разбор URL-адреса представляет собой весьма сложную задачу, которая, к сожалению, не достаточно четко определена.

Примером может служить URL-адрес перечня опечаток для настоящей книги - http://www.boyet.com/dads. Он состоит из трех частей. Первая, "http://" определяет протокол, вторая, "www.boyet.com", указывает имя сервера, а третья, "/dads" - имя папки на сервере.

Перед написанием пакета тестов для проверки модуля синтаксического разбора URL-адресов было вполне обычным делом внести исправление, которое позволяло правильно разбирать одну часть адреса, но вызывало ошибку при разборе другой части адреса.

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

Тестовый каркас Dunit можно найти в Internet по адресу http://dunit.sourceforge.net. Все коды, приведенные в книге, были протестированы с помощью тестов, написанных с использованием Dunit. Некоторые тесты включены в материалы, сопровождающие книгу, которые доступны на Web-сайте издательства.