Материал: ВВПИ. Лекции
Рис. 14.5. Настройка получателей оповещений.
Оповещения, рассылаемые TFS, содержат только базовую информацию о произошедшем событии и ссылку, позволяющую просмотреть детали о события через Internet Explorer, на Share Point портале проекта. В частности, информация о результатах автоматической сборки и о тех ошибках, исправления которых вошли в соответствующую ей версию исходных кодов проекта, представлена на рис. 14.6.
136
Build Night build_20081123.2
Summary
Build name:
Requested by:
Team project:
Definition name:
Agent name:
Command-line arguments:
Started on:
Completed on:
Last changed by:
Last changed on:
Quality:
Work items opened:
Source control version:
Log:
Partially Succeeded
Night build_20081123.2
LANDOCS\arhangel
TestProject
Night build
TestProject
23.11.2008 17:36:56
23.11.2008 17:38:24
LANDOCS\TFSBuild
23.11.2008 17:38:24
Not available
C1479
\\landocs\TestProjectBuild\Night build_20081123.2\BuildLog.txt
…
Associated work items |
|
|
|
ID |
Title |
State |
Assigned To |
107 |
Use Visual Studio core editor for SQL editing |
Closed |
arhangel |
|
|
|
|
235 |
Build failure in build: Night build_20081123.1 |
Resolved |
TFSBuild |
|
|
|
|
Note: All dates and times are shown in Russian Standard Time (GMT +03:00:00).
Provided by: Microsoft Visual Studio® Team System 2008.
Рис. 14.6. Результаты автоматической сборки.
Модульные тесты
Модульные тесты как средство повышения качества программного обеспечения появились достаточно давно, однако они долго оставались не поддержанными продуктами Microsoft. Впервые поддержка модульных тестов появилась в Visual Sutiod 2005 и доступна в изданиях Professional и выше (в том числе, и во всех изданиях группы Team).
Основная идея модульных тестов заключается в том, что работоспособность кода можно проверить автоматически с помощью написания дополнительного кода, вызывающего тестируемы и анализирующего результаты. При этом, если для системы в целом такой подход достаточно затруднителен в виду сложности системы, то для отдельных частей системы (модулей), этот метод применим и дает хорошие результаты. Как правило, основной единицей для модульного тестирования являются классы и методы классов.
Исторически одним из первых популярных инструментов, ориентированных на организацию модульного тестирования, был jUnit для Java-приложений, клонированный затем под многие другие платформы. Для платформы .NET пионером здесь являлся nUnit, который до сих пор занимает лидирующую позицию в этой нише. Однако, лидерство nUnit серьезно пошатнулось с появлением поддержки модульных тестов в Visual Studio. По сравнению с классическими системами Visual Studio обладает рядом следующих преимуществ.
•Поддержана полная интеграция в пользовательский интерфейс, включая запуск и анализ результатов (для других систем интеграция доступна за отдельные деньги и не так обширна).
137
•Реализованы возможности для легкой интеграции в средства автоматической сборки (только для TFS Team Build).
•Предложены дополнительные средства для описания процедуры развертывания теста (больное место большинства остальных систем) и конфигурации других аспектов выполнения.
•Имеются средства автоматической генерации сигнатур тестов и средств доступа к приватным частям тестируемых классов.
•Поддержано управление тесnовыми данными, а также тестами, использующими данные на уровне платформы.
Вверсии Visual Stuido 2008 поддержка модульного тестирования была перенесена из изданий семейства Team в издание Professional, что было вполне логичным шагом, так как модульное тестирование является общей практикой, применяемой как в личной, так и
вкомандной разработке. Так как модульное тестирования более не является чем-то специфичным для Visual Studio Team System, а его реализация соответствует большинству стандартных пакетов в этой области, мы не будем останавливаться на этой возможности более подробно.
Пакеты тестов
Как правило, модульные тесты и тестовые конфигурации разрабатываются самими разработчиками, основная задача тестера в этом случае – организовать все тесты в упорядоченную структуру пакетов и указать, какие пакеты должны исполняться в каких условиях. Вся иерархия тестов хранится в так называемом файле метаданных, имеющем расширение vsmdi. Этот файл находится в системе контроля версий и может быть включен в решение как отдельный элемент – см. рис. 14.7.
138
Рис. 14.7. Пакет с иерархией тестов.
Для создания тестового пакета можно воспользоваться меню «Create New Test List», как показано на рис. 14.8, и после этого откроется окно для задания имени нового пакета и определения его места в иерархии тестовых пакетов (см. рис. 14.9). В том случае, если для решения уже создан файл метаданных, пакет тестов будет добавлен к нему, если же файла метаданных еще создано не было, он будет создан автоматически.
Рис. 14.8. Создание списка тестов.
139
Рис. 14.9. Свойства нового списка тестов.
Содержимое пакетов тестов редактируется с помощью специального редактора, показанного на рис. 14.10. В пакеты могут быть включены тесты, находящиеся в одном из проектов текущего решения.
140