Тестирование - Программирование от RIN.RU

Отладочная и коммерческая версии кода

Те, кто участвовали в "полевых испытаниях" (известных как бета-тестрирование) коммерческих программ, наверняка обратили внимание, что такие версии программ более медлительны, гораздо более "разговорчивы" и размером побольше окончательных версий программ. Может быть, разработчик спешил и выпустил "сырой" продукт, который будет улучшать перед выпуском окончательного варианта? Так тоже бывает, но главная причина в другом: в бета-версии содержится тестовый и отладочный коды, используемые разработчиком для проверки корректности работы программы.

Delphi позволяет очень легко внести тестовый и отладочный коды в приложение. Например, вы хотите создать приложение работы с базой данных и использовать быстрый, но, возможно, несколько рискованный алгоритм сортировки данных. Как же убедиться в корректности его работы? Один из путей - использовать в приложении два алгоритма одновременно (быстрый, но рискованный, и медленный, но проверенный), затем сравнить результаты работы обоих алгоритмов. Конечно же, этот вариант используется только в бета-версии, и после всестороннего тестирования, если все работает отлично и без сбоев, в конечной версии продукта останется только быстрый (и после такого тестирования - уже не рискованный) метод сортировки.

Для этого вам вовсе не надо использовать два разных текста программ - воспользуйтесь возможностью условного компилирования. Вы можете определить символ (я обычно использую Debug, но вы свободны в вашем выборе) для переключения между коммерческой и отладочной версиями вашего кода с использованием директив $IFDEF, $IFNDEF, $ELSE и $ENDIF. Вот пример использования "медленного" алгоритма в отладочной версии.


DataSet:= GetData; //Получение данных для сортировки. 
    {$ifdef Debug} 
    TestResultSet:= Sort_Tortoise(DataSet); //Медленно и надежно. 
    {$endif} 
    ResultSet:= Sort_Hare(DataSet); //Быстро и рискованно. 
    {$ifdef Debug} 
    if not CompareData(ResultSet, TestResultSet) then 
        //Результаты совпали? 
    Raise Exception.Create('Сортировка в DataSorting некорректна'); 
    {$endif}

Если определен символ Debug, код принимает следующий вид.


DataSet:= GetData; //Получение данных для сортировки. 
    TestResultSet:= Sort_Tortoise(DataSet); //Медленно и надежно. 
    ResultSet:= Sort Hare(DataSet); //Быстро и рискованно. 
    if not CompareData(ResultSet, TestResultSet) then 
        //Результаты совпали? 
    Raise Exception.Create('Сортировка в DataSorting некорректна');


DataSet:= GetData; //Получение данных для сортировки. 
    Re5ultSet:= Sort_Hare(DataSet); //Быстро и рискованно.

Как видите, использование условной компиляции - простои способ создания как отладочной, так и коммерческой версий приложения Вы можете определить символ условной компиляции двумя путями. Первый - глобальное определение символа в опциях проекта. Выберите команду Project/Options и в диалоговом окне Project Options, во вкладке Directories/Conditionals, введите символ в поле Conditional defines. На рисунке ниже показано определение двух символов (Debug и Alpha) Щелкните на кнопке ОК для подтверждения вашего ввода

Совет: Изменив символы условной компиляции, перекомпилируйте проект с помощью команды Project/Build All для того, чтобы учесть внесенные изменения.

Другой метод определения символа условной компиляции - вставить в ваш исходный код директиву.

{$define Debug}

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

{$undef Debug}

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

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

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

Использование директивы Assert

Оператор Assert- новый оператор в Delphi 4. В действительности это просто тест на логическую истину/ложь. При использовании этого оператора вы убеждаетесь, что логическое выражение истинно, если при выполнении выражение становится ложным, генерируется исключительная ситуация. Синтаксис использования оператора таков:

Assert (<логическое выражение)

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

    procedure Foo(Count: Cardinal); 
    begin 
        Assert(Count < SizeOf(Word)); 
    end;

Если выражение окажется ложным, появится сообщение об ошибке. Конечно же, у вас уже вертится на языке вопрос, чем же это отличается от конструкции if... else. Дело в том, что управлять генерацией кода для оператора Assert очень легко и просто с помощью директивы компилятора. Для применения описанных возможностей используйте директиву $ASSERTIONS ON или $С +, а для отключения действия Assert- $ASSERTIONS OFF или $С - (при этом компилятор игнорирует операторы Assert и код для них не генерируется).

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

    {$ifdef Debug} 
    ($ASSERTIONS ON) 
    {$else} 
    ($ASSERTIONS OFF) 
    {$endif}

Какого типа выражения могут использоваться в операторе Assert? Любого (конечно, если оно возвращает логическое значение). Однако тут есть свои маленькие подводные камушки, о которые легко поцарапаться. Представьте себе, что у вас есть некоторая функция, например выясняющая, сколько раз она была вызвана.

    function CountMe: Integer; 
    const ReferenceCount: Integer = 0; 
    begin 
        Inc(ReferenceCount); 
        Result:= ReferenceCount; 
    end;

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

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

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

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

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