 |
|
|
|
Тестирование приложений при разработке. Функциональное и модульное тестирование
Тестирование приложений при разработке Практические рекомендации по использованию модульных и функциональных тестов с использованием NUnit и Rhino Mocks для тестирования C#-приложений Тестирование приложений на этапе разработки должно быть обязательным перед подготовкой их к выпуску (release). Чем раньше удастся обнаружить ошибки, тем ниже стоимость их устранения [1]. Например, для водопадной модели жизненного цикла разработки программ зависимость цены ошибки от стадии проектирования и времени обнаружения представлена на рис.1 [2].
Рисунок 1. Зависимость цены устранения ошибки от стадии проектирования и времени обнаружения [2] Тестирование – мощный инструмент для обнаружения ошибок и повышения качества программного обеспечения, иногда с его помощью можно обнаружить дефекты, заложенные на этапах написания технического задания и разработки архитектуры приложения по ТЗ, что намного лучше, чем разгребать ошибки в уже проданном программном обеспечении (страдают как репутация фирмы, так и люди, сопровождающие продукты). Тестирование дает возможность обнаружить те ошибки, которые проявляются редко или очень редко при не совсем обычных условиях (когда переменным присваиваются null-значения, есть пустые строки, зависимость от регистра в строках символов и так далее). От качества тестов зависит количество ошибок, которое может быть обнаружено. Написание качественных тестов – искусство. В настоящее время часто применяют модульное, функциональное, нагрузочное и интеграционное и некоторые другие виды тестирования. Модульные (unit) тесты используются для проверки состояния объектов в результате и процессе вызова интерфейсных методов, а также для исследования последовательности вызовов интерфейсных методов. В модульных тестах обычно тестируемые классы изолируют от реальных объектов (файлов конфигурации, баз данных, сетевых соединений и т.д.). Как правило, используются библиотеки (Rhino Mocks, Google С++ Mocking Framework, JMock и др.) для создания заглушек (stub) и эмуляторов (mock) реальных объектов. В функциональных тестах исследуется взаимодействие тестируемых классов с реальными объектами. Нагрузочное тестирование позволяет проверять производительность API и GUI (интерфейс пользователя) приложений. А интеграционные тесты используют для проверки взаимодействия приложения с внешними сервисами. К сожалению, не всегда можно обойтись заглушками и моками, особенно если взаимодействие приложения с сервисами является достаточно сложным. В моей практике разработчика модульные и функциональные тесты позволили быстро исправить API при изменении структуры базы данных и изменениях в интерфейсах классов, а также обнаружить ряд довольно критичных ошибок. Особенно важны модульные тесты при работе с унаследованным кодом, при добавлении новой функциональности в существующий проект. Инструменты для проведения модульного и функционального тестирования в C#: NUnit и Rhino Mocks Для проведения модульных и функциональных тестов существуют библиотеки NUnit и Microsoft Unit Test. Библиотека NUnit обладает большей гибкостью, чем библиотека модульных тестов от Microssoft. Для использования NUnit в проектах необходимо добавить ссылку (Reference) на сборку NUnit. VisualStudio 2010, 2012, 2013 и SharpDevelop, добавить NUnit через Nuget Package Manager, в консоли набрать команду: PM> Install-Package NUnit Для работы с NUnit в более ранних версиях Visual Studio, например, в 2008-й, необходимо установить NUnit с помощью отдельного установщика библиотеки [3], так как менеджер библиотек включен в Visual Studio начиная с версии 2010. После установки NUnit к проекту тестов требуется добавить ссылку на сборку NUnit, а в классы тестов добавляем директиву использования библиотеки: using NUnit.Framework; Для использования библиотеки модульных тестов Microsoft необходимо создать проект модульного тестирования и добавить директиву: using Microsoft.VisualStudio.TestTools.UnitTesting; Более подробно см. на MSDN [4]. Статью целиком читайте в журнале «Системный администратор», №1-2 за 2014 г. на страницах 89-93. |
МИХАИЛ УШАКОВ, разработчик электронной аппаратуры и программного обеспечения для ядерной гаммарезонансной спектроскопии, Уральский федеральный университет, ![Рисунок 1. Зависимость цены устранения ошибки от стадии проектирования и времени обнаружения [2]](../../../../uploads/articles/2014/01-02/089_093_Application_Testing_During_Development/1.gif "Рисунок 1. Зависимость цены устранения ошибки от стадии проектирования и времени обнаружения [2]")
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
