Автономная отладка модуля

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

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

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

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

Восходящее и нисходящее тестирование имеет свои достоинства и недостатки.

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

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

Автономное тестирование целесообразно осуществлять в 4 последовательных шага:

C#

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

Встроенный комментарий нужно применять осторожно, он ухудшает читабельность кода, однако, удобен при отладке. Если символы комментариев будут включены внутри строковых литералов, то они комментарием не являются (например, string s = “ /* это простой текст */ “;)

При написании программного кода, все комментарии подсвечиваются зеленым цветом.

Каждый XML комментарий начинается с трех символов слеша (///). Первые два слеша указывают, что это комментарий и запрещает компилятору его обрабатывать. А третий слеш сообщает синтаксическому анализатору, что это XML комментарий. Когда разработчик набирает 3 символа слеша подряд, то интегрированная среда разработки (IDE) проверяет не предшествует ли она распознаваемому типу, если да, то IDE автоматически вставляет некоторые теги, после чего разработчик сам может теги убрать или добавить другие.

XML-теги бывают следующих видов

/// <remarks> - ремарка класса

/// текст

/// </remarks>

Рекомендуется применять тег для описания типа. Автоматически <remarks> не вставляется (его нужно вставлять вручную).

<summary> - он описывает элементы типа, включая методы свойства и поля. Как правильно он идет сразу за <remarks>

<remarks> описывает тип, а <summary> описывает элементы или экземпляры этого типа, а также структуру типа

<example> выделяет пример использования элемента. В качестве примера может быть фрагмент кода. Если используется пример программного кода, то используется дополнительный тег <code>.

<exception cref=”Sample Exception”> документирует исключения, которые генерирует документ (например, деление на 0). Для описания нескольких исключений используют несколько таких тегов (сколько исключений, столько и таких тегов). Тег имеет атрибут cref его значение – это имя исключения, хотя исключения можно необязательно писать латиницей.

<param name=”strFilePath”> описывает параметры метода или свойства (аргументы подпрограмм). Имеет параметр name, его значение должно совпадать с именем аргумента. Количество таких тегов должно быть равно количеству параметров.

<permission cref=”….”> разрешение на доступ к элементам (содержит описание разрешения). Это может быть информация о виде разрешения на доступ, например, открытый элемент/закрытый элемент/защищенный элемент), область видимости и т.д. Требований к значениям в этом теге нет. Описывается как ссылка на элемент или поле, доступный из текущей среды компиляции.

<returns> описывает возвращаемое значение метода или свойства. В случае методов, применяется только к функциям (например, sin).

<seealso cref=”….”/> указываются прочие ссылки по тематическому разделу. Содержит только атрибут cref со ссылкой на нужный символ.

<include file=’MyXML.xml’

path = ‘doc/members />