Чтение онлайн

...

{$IFDEF UseAssert}

Assert (MyPointer <> nil, "MyPointer should be allocated by now");

{$ENDIF}

MyPointer^.Field := 0;

...

Преимущество последнего метода заключается в том, что процедура в окончательном варианте выполняемого файла отсутствует совсем. Поскольку в настоящей книге все коды предназначены для компиляции на всех версиях Delphi, используется процедура Assert, код которой показан в листинге 1.7.

Проверка утверждений может применяться тремя способами: предусловие, постусловие и инвариант. Предусловие (pre-condition) - это утверждение, находящееся в начале функции. Оно однозначно указывает, какое условие, касающееся окружения и входных параметров, должно соблюдаться перед выполнением функции. Например, предположим, что создана функция, которой в качестве параметра передается объект. При этом разработчик решил, что функции не должен передаваться nil. Помимо доведения этой информации до всех разработчиков, он должен в начале функции вставить утверждение, которое будет проверять, передается ли функции nil. В таком случае, если сам разработчик функции или кто-то из его коллег забудет о существующем ограничении, предупреждение напомнит об этом.

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

И последний тип утверждений - инвариант (invariant). Он представляет собой нечто среднее между предусловием и постусловием. Это утверждение, которое находится в середине кода и гарантирует, что определенная часть функции выполняется корректно.

Единственной проблемой, связанной с утверждениями, является выбор случая, когда они более предпочтительны, чем "нормальные" исключения. Это малоисследованная область, но мы постараемся охватить и ее. В общем случае, ошибки, обнаруживаемые при тестировании, можно разбить на два типа: ошибки программиста и ошибки входных данных. Давайте попытаемся разобраться, в чем же состоит отличие между этими двумя типами.

Классическим примером может служить исключение "List index is out of bounds" (Индекс в списке вышел за допустимые пределы), особенно тот случай, когда используется индекс -1. Ошибка подобного типа вызвана тем, что программист не проверяет индекс элемента перед тем, как записать или считать его из TList. Код объекта TList проверяет все передаваемые ему индексы элементов. Если индекс находится вне допустимого диапазона, возникает исключение. Пользователь приложения не может вызвать такую ошибку (по крайней мере, это покажется глубоко бессмысленным для большинства пользователей). Ошибка возникает исключительно из-за недостаточного объема проведенного тестирования. По мнению автора, это исключение должно быть утверждением.

А теперь рассмотрим другой случай. Предположим, что мы разрабатываем функцию, которая должна разворачивать данные из файла, например, из архива. Формат сжатого файла достаточно сложен, по крайней мере, он считается простой последовательностью битов, и все последовательности выглядят примерно одинаково. Если в последовательности битов функция разархивирования встретит ошибку (например, последовательность исчерпана, но логически она не закончилась), будет это утверждением или же исключением? По мнению автора, это должно быть простым исключением. Вполне вероятно, что функции в качестве входных данных будут переданы поврежденные файлы или файлы, которые не являются архивами в требуемом формате. Очевидно, что это ошибка не программиста. Она полностью вызвана внешними условиями.

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

Комментарии

Это правило выглядит достаточно просто:

– ---

Правило № 3. Помещайте в код комментарии. Объясняйте ваши допущения (более того, проверяйте их с помощью утверждений). Описывайте сложные блоки кода. При изменении кода изменяйте и соответствующие комментарии. Не допускайте, чтобы комментарии устаревали.

– ---

Протоколирование

Рассмотрим еще одно средство из арсенала защитного программирования -протоколирование (logging). Под протоколированием здесь понимается вставка дополнительного кода, закрытого директивами компилятора, который записывает в файл состояние или значения основных переменных.

Этот метод уходит корнями в те времена программирования на языке Pascal, когда программисты при любом удобном случае вставляли оператор writeln и надеялись, что он поможет обнаружить ошибку. В наши дни ценность этого метода существенно снизилась. Автор книги зачастую для протоколирования состояния классов пишет методы DumpToFile. Их можно помещать в условные блоки компилятора, вызывать несколько раз в стратегически важных точках и получать описание всего жизненного цикла определенного объекта.

– ---

Правило № 4. Пишите код протоколирования и защищайте его директивами компилятора. Однажды протокол может пригодиться, и вполне вероятно, что такой день таки наступит.

– ---

В кодах, приведенных в книге, будут приведены примеры использования этого метода.

Трассировка

В прошлом трассировка была тесно связана с протоколированием. Трассировка (tracing) представляла собой метод вставки операторов writeln в начале и в конце функций. Операторы применялись для вывода на экран или в файл таких простых сообщений, как "Вход в функцию X" или "Выход из функции X". Запись сообщений в файл помогала восстановить ход выполнения приложения и порядок вызова функций. В настоящее время существуют специальные программы, которые делают все это сами, без участия программиста. Приложение запускается внутри такой программы, а она автоматически идентифицирует все функции и подпрограммы, их начало и завершение, и формирует журнал трассировки приложения. Никаких изменений вносить в код не потребуется.

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

Анализ покрытия

Это современный метод и для его использования вам понадобится специальное программное обеспечение. Анализ покрытия (coverage analysis) представляет собой запись в журнал того, какие операторы приложения были "покрыты", т.е. выполнены. Если при тестировании отдельная строка или блок кода не выполняются, в этой строке или блоке может содержаться ошибка. Такую ошибку можно будет выявить только с помощью теста, при выполнении которого выполняется код с ошибкой.

– ---

Правило № 5. При тестировании пользуйтесь анализатором покрытия. Убедитесь, что во время тестирования выполняются все строки кода.

– ---

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

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

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

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

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

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