----
Правило № 5. При тестировании пользуйтесь анализатором покрытия. Убедитесь, что во время тестирования выполняются все строки кода.
----
Тестирование модулей (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-сайте издательства.
При разработке приложений всегда наступает момент, когда приходится переходить к поиску и устранению ошибок. В настоящей книге мы не будем подробно описывать процесс отладки, давать советы по использованию отладчика и описывать методы поиска и устранения основных типов ошибок. Здесь будут приведены лишь основные правила, которые позволят читателю существенно упростить сам процесс отладки. Все они взяты из книги Роббинса (Robbins) [19].
----
Правило отладки № 1. Выбирайте воспроизводимый случай тестирования.
----
По нечеткому описанию проблемы можно обнаружить только самые простые ошибки. Тестовый случай, который при необходимости может воспроизвести ошибку, - это, по крайней мере, 90% на пути к ее обнаружению и устранению. Возможность воспроизведения ошибки позволяет с помощью отладчика определить место, где она возникает. Если же у вас нет теста, который может воспроизвести ошибку, то у вас нет и надежды.
Второе правило отладки намного сложнее.
----
Правило отладки № 2. Исходите из того, что ошибка внесена вами.
----
Может быть, вы неправильно используете API-интерфейс операционной системы или библиотека компонентов требует определенной последовательности операций. Или, в конце концов, может быть, вызываемая вами функция не может принимать nil в каком-либо входном параметре. Маловероятно, чтобы ошибка была вызвана неправильной работой API-интерфейса или компилятора. Более вероятно, что ошибка присутствует в библиотеке компонентов, тем не менее, попытайтесь выделить проблему (см. правило отладки 1), что позволит с уверенностью сказать, что ошибка находится не в вашем коде. Конечно, если ошибка находится не в вашем коде, ваша задача только усложняется, поскольку придется положиться на разработчиков операционной системы, компилятора или библиотеки компонентов, что они достаточно быстро устранят имеющуюся проблему.
Следующее правило вытекает из уже рассмотренного нами материала.
----
Правило отладки № 3. Для проверки того, что код работает, как того ожидалось, используйте утверждения.
----
Кроме того, можно применять и протоколирование, которое позволит отслеживать состояние различных объектов.
А теперь перейдем собственно к отладке.
----
Правило отладки № 4. Используйте автоматизированные инструментальные средства отладки.
----
Возможно, ваша ошибка вызвана перезаписью какой-то области памяти или получением доступа к памяти после того, как она была освобождена, либо, скажем, при вызове API-функции не проверяется код возвращаемой ошибки. Все описанные типы проблем можно обнаружить в таком автоматизированном средстве отладки, как TurboPower Sleuth QA Suite. Приобретите средство отладки и используйте его не только в процессе тестирования, но и в процессе обнаружения ошибок.
Естественно, после этого следует сама отладка, которая может выполняться даже с помощью отладчика. Именно здесь наука программирования превращается в настоящее искусство. Отладку нельзя назвать алгоритмом, скорее, это соревнование. Единственным советом в этом соревновании может быть "не делайте никаких допущений". Если вы считаете, что некоторая переменная должна содержать определенное значение, проверьте это. Пользуйтесь средством визуализации значений отладчика. Для наблюдения за блоком памяти можно воспользоваться окном процессора. Попытайтесь предсказать значения переменных, а затем проверить свои предположения и при необходимости устраните ошибки. Без боязни добавляйте в код новые утверждения с целью проверки своих предположений.
Эта глава была достаточно насыщена информацией и, честно говоря, была посвящена не столько алгоритмам и структурам данных, сколько технологиям увеличения быстродействия кода и процедурным методам.
Иногда быстродействие является результатом правильного выбора алгоритма или структуры данных (или того и другого). В других случаях увеличение скорости может быть достигнуто благодаря глубоким знаниям оборудования компьютера и операционной системы. Прежде всего, важно понимать, что единственным методом увеличения быстродействия приложения является использование профилировщика. Только предоставляемая профилировщиком статистика поможет определить, на что приложение тратит время, и лишь глубокое изучение отдельных блоков кода позволит оптимизировать приложение и увеличить его быстродействие. Хотелось бы подчеркнуть, что просто выбор "правильного" алгоритма или структуры данных отнюдь не означает, что приложение будет работать быстрее. Приведенная в книге информация поможет вам понять возможные способы ускорения выполнения отдельных частей кода, но только не нужно вносить в код сложные реализации алгоритмов там, где этого не требуется - вы только зря потеряете время.
Кроме того, в этой главе мы кратко рассмотрели тестирование и отладку - это тоже не алгоритмы, а скорее методы, гарантирующие, что код не содержит ошибок. А если ошибки все-таки присутствуют, то в коде находится столько разного рода следов и указателей, что поиск и устранение ошибок не должны отнимать много времени.
Несмотря на то что при стандартном (и не совсем стандартном) программировании используется огромное количество разного рода структур данных, большинство из них основаны на одном из двух фундаментальных контейнеров: массив и связный список. Если после прочтения этой книги вы научитесь правильно применять эти два типа структур, цель книги можно будет считать достигнутой. Они важны не только благодаря своей простоте, но и вследствие своей высокой эффективности. Массивы будут подробно рассмотрены в этой главе, а связные списки - в следующей. Кроме того, в главе 3 после связных списков будут описаны некоторые простые типы структур данных, основанные на этих двух фундаментальных типах. В главах 4 и 5, посвященных поиску и сортировке соответственно, мы также коснемся фундаментальных типов структур данных, но под несколько другим углом.
Невзирая на то что в книге будут приводиться полные реализации этих двух типов структур данных, иногда будет удобнее написать свою собственную реализацию. Поэтому важно четко понимать все аспекты, которые будут рассматриваться в этой и последующих главах.
Во многих отношениях массивы являются простейшей структурой данных. Проще могут быть только такие базовые типы данных, как integer или Boolean. Массив (array) представляет собой последовательный список определенного количества элементов. Все элементы в массиве принадлежат к одному типу данных, и, как правило, хранятся в одном блоке памяти, т.е. каждый последующий элемент в памяти находится непосредственно после предыдущего. В таком случае говорят, что элементы массива являются смежными в памяти. Если ссылаться на элементы массива по их числовым индексам, то первый элемент будет иметь индекс 0 (или 1, или любое другое число, по крайней мере, в Delphi), значение индекса второго элемента будет больше на единицу и т.д. В коде элемент с индексом i обозначается как А[i], где А - идентификатор массива.
В Delphi имеется большой набор встроенных типов массивов. Кроме того, отдельные удобные типы массивов определены в библиотеке визуальных компонент VCL (Visual Component Library) в виде классов (и не только классов). Для поддержки таких классов, как массивы, разработчики Delphi предусмотрели возможность перегрузки операции массива, [], добавляя к нему новые свойства. Это единственная операция в Delphi, помимо + (сложение и конкатенация строк), которую можно перегружать.
В Delphi имеется три типа поддерживаемых языком массивов. Первый - стандартный массив, который объявляется с помощью ключевого слова array. Второй тип был впервые введен в Delphi 4 в качестве имитации того, что было давным-давно доступно в Visual Basic, - динамический массив, т.е. массив, длина которого может изменяться в процессе выполнения кода.
И последний тип массивов, как правило, не считается массивом, хотя в языке Object Pascal имеется несколько его вариаций. Конечно, мы говорим о строках: однобайтных строках (тип shortstring в 32-разрядной версии Delphi), строках с завершающим нулем (тип Pchar) и длинных строках в 32-разрядных версиях Delphi (которые имеют отдельную вариацию для "широких" символов).
Все массивы имеют одну и ту же структуру. Они состоят из одного или большего количества повторений другого типа данных, например, char, integer или record, которые в памяти находятся рядом друг с другом. Именно это последнее свойство стандартных массивов позволяет очень быстро получить доступ к отдельным элементам массивов. Весь процесс доступа к элементу сводится к простому вычислению адреса, для чего требуются, как мы вскоре увидим, всего несколько машинных инструкций.
Можно даже не сомневаться, что все вы знаете стандартный способ объявления массивов в Delphi. Так, объявление