Файл: Освой самостоятельно программирование для MS Access 2002 за 24 часа [П.Киммел].pdf

Часть VI

Работа над

Темы занятий

 час.

 кода

 час. Обработка ошибок во время выполнения программы

 час

 кода

Термином

 bug,

 широко распространенным в сообществе создателей программного

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

 поль-

зователям обернуться огорчениями и разочарованиями. На этом занятии речь пойдет о

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

Следует отметить, что задача поиска ошибок в профамме нерешаема только в том

случае, если сам

 код непоследователен, неряшлив и запутан. В этой

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

Основные темы занятия.

• Пошаговое тестирование профаммного кода.
• Приемы эффективной отладки.
• Использование условных директив компилятора.

Тестирование кода

В компьютерной науке широкую известность получила так называемая

 проблема

неразрешимости.

 Если не вдаваться в математические детали, ее можно сформулиро-

вать так: в настоящий момент не существует строгого алгоритма, способного доказать
правильность результатов выполнения кода профаммы при всех возможных условиях.
Говоря проще, никто не может дать полных гарантий того, что конкретная профамма
(независимо от степени ее сложности) не содержит никаких ошибок.

 Новый термин

Термин

 алгоритм

 обычно используют для ссылки на процедуру или

функцию. В некоторых случаях под алгоритмом понимают набор связан-
ных функций.

Таким образом, факт безошибочности профаммного кода недоказуем. Отсюда следует,

что всякий код может (и даже должен) содержать ошибки. (Самый красноречивый пример
связан с нашумевшей проблемой неверной трактовки дат, следующих за

 декабря 1999

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

 полностью

 свободный от ошибок,

 относительно

"чистый" программный продукт — это тот идеал, к которому нужно стремиться. Но каков

же должен быть опыт, чтобы не допускать ошибок, чтобы быстро их отыскивать в нужных
случаях? Это как раз тот вопрос, на который вы найдете ответ в этой главе.

Предлагаем несколько советов, которые помогут определить тот объем работы, ко-

торый следует выполнить, чтобы убедиться в надежности написанного кода. Итак,
первый этап — это

 промежуточное тестирование.

В последнее время все большую популярность завоевывает

автоматизирующий тестирование для Java. Вероятно, сходные с JUnit
тесты будут в ближайшее время созданы и для других языков програм-
мирования. Кроме того, все большее внимание уделяется реструкту-
ризации задач. Это наиболее формальный подход к созданию программ,
когда сходные части кода выделяются в отдельный блок — подпрограмму
или функцию. Данному вопросу

 прекрасная книга Мартина

Фаулера (Martin Fowler)

 the Design of Existing Code,

которая вышла в издательстве

 Указанное издание пред-

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

Почти все программисты, с которыми мне когда-либо приходилось встречаться,

говорили, что они тестируют свой код. Но как и когда именно? Какое количество ко-

да подвергается единовременному тестированию? Эти вопросы весьма важны.

Следует тестировать

 маленькие

 порции написанного кода. Если вы создали функ-

цию, которая будет реализовывать некоторую часть общего замысла, тут же отдельно
ее и протестируйте. Например, удачными объектами промежуточного тестирования
служат функции сортировки, рассмотренные в главе "12-й час. Управление данными
переменного объема". Каждая из них представляет собой законченное решение зада-

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

Для тестирования отдельных строк кода и пошагового тестирования

отдельных подпрограмм используйте окно Immediate в редакторе Visual

Basic. Это прекрасный способ первичного тестирования, но он не столь

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

Удобными объектами независимого промежуточного тестирования можно назвать

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

 протестировать отдельно и только потом — в

совокупности.

О важности промежуточного

Во время работы над программой ее автор не может не помнить о состоянии

"ближайших" объектов кода и данных. Создавая функцию или процедуру, человек

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

Например, намереваясь изменить содержимое набора данных Recordset, програм-

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

298

Часть VI. Работа над ошибками

Вот почему тестировать фрагменты кода необходимо сразу же после их написа-

ния — ни в коем случае не позже. Иначе вы рискуете упустить из виду какие-нибудь

ранее предусмотренные аспекты поведения программы.

Что именно следует тестировать

Важно понимать,

 что именно

 должен проверять тестовый код. Естественно, первым

дело стоит проверить основные

 но вообще код должен быть

"прощупан" всеми мыслимыми случайными наборами входных данных. При создании

тестовых процедур программисты обычно делают упор на проверке штатных — типич-

ных и предусмотренных — ситуаций. Конечно, код должен работать с той информаци-

ей, характеристики которой вы заранее проанализировали. Ну, а что случится, если дан-

ные выйдут за пределы "разумных" рамок? Тестовая процедура должна проверить кор-

ректность ваших предположений и, возможно, выявить случаи, которые остались неза-

меченными. Процесс промежуточного тестирования заставляет вас воспринимать

небольшой фрагмент кода как решение самостоятельной равноправной задачи.

Тестовый код имеет значение не только для вас, автора программы, но и для ва-

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

 что

вы учли, а что осталось за пределами внимания. Народная мудрость "Одна голова хо-

рошо, а две лучше" еще раз доказывает свою истинность.

Следующий ряд вопросов, затрагиваемых в ходе промежуточного тестирования,

связан с выявлением необоснованных

 взаимозависимостей

 различных фрагментов ко-

да. Подобные факты служат признаком незрелости кода и свидетельствуют о непро-

фессионализме его автора. Например, если алгоритм быстрой сортировки

(см. главу 12) реализован так, что он не работает в виде отдельной функции, следует

пересмотреть такое решение полностью.

Еще одно неявное и необходимое следствие применения технологии

промежуточного тестирования состоит в выработке навыков создания

независимых фрагментов кода.

Следует стремиться полностью избавиться от взаимозависимостей функций и про-

цедур. То же справедливо и в отношении классов; класс должен содержать все атрибу-

ты, необходимые и достаточные для решения поставленной перед ним задачи.

Как тестировать программный код для Access

Чтобы выполнить промежуточное тестирование программных решений в среде Ac-

cess, целесообразно иметь вспомогательную базу данных. Пустая база — хороший от-

правной пункт, поскольку в этом случае принимаются во внимание ситуации, когда

исходные данные отсутствуют. Ниже приведена общая последовательность действий,

необходимых для тестирования кода Access.

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

2. Создайте новый модуль, если вы собираетесь тестировать процедуру (функцию),

либо добавьте класс, подлежащий тестированию.

3. Напишите подпрограмму, которая вызывает тестируемый блок кода с передачей

верного числа параметров требуемых типов.

4. Запустите программу на выполнение в режиме отладки.

Если ваш код прошел все стадии, перечисленные в приведенном ниже списке,

значит, он в достаточно хорошей

17-й час. Отладка кода 299