Unit tests

Цуканов Павел

ptsukanov@codereign.net

Unit тесты теория и практика

Содержание• Что такое Unit тесты и с чем их едят

• Unit Test инструменты

• Изоляция в Unit тестах

• От теории к практике

• Вредные советы

• Требования к тестам

• Правила оформления

Что такое Unit тесты и с чем их едят

• Unit – это атом тестирования.

• Тест пишут программисты

• Тесты показывают насколько корректно работает та или иная часть программы

Преимущества Unit тестов• Поощрение изменений

• Упрощение интеграции

• Документирование кода

• Отделение интерфейса от реализации

Ограничения Unit тестов• Unit тесты могут показать только наличие ошибки, а не

их отсутствие.

• Тесты требуют много кодирования (тесты могут занимать от 50 до 80%).

• Не всё можно проверить

• Сам тест может содержать ошибки

• Важна строгая дисциплина при разработке. Тесты должны быть запущены вовремя и выявленные ошибки были немедленно устранены

Unit Test инструменты• Unit тесты разрабатываются для различных языков

программирования (см. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks)

• Для создания тестов нужен framework. Наиболее часто используемые для .Net

• Nunit (www.nunit.com)

• xUnit ( xunit.codeplex.com)

• Visual Studio Unit Test Framework

• Интеграция со средой разработки.

• ReSharper

• TestDriven.net

• Visual Studio

• Continuous integration серверы.

• TeamCity

• CruiseControl

• Team Foundation Server

Изоляция в Unit тестах• Тест не должен иметь других зависимостей, чем сам

тестируемый код

• Это нужно для того, чтобы исследовать поведение тестируемого кода, а не его окружения (другого кода или ресурсов)

• По степени изоляции тесты можно разделить на

• Unit тесты

• Интеграционные тесты

• Функциональные тесты

• Системные тесты

Изоляция. Unit тесты

Unit тест

Class

Class

Class

Внешний

ресурс

Внешний

ресурс

Изоляция. Интеграционные тесты

Unit тест

Class

Class

Class

Внешний

ресурс

Внешний

ресурс

Изоляция. Функциональные тесты

Unit тест

Class

Class

Class

Внешний

ресурс

Внешний

ресурс

Изоляция. Системные тесты

Unit тест

Class

Class

Class

Внешний

ресурс

Внешний

ресурс

Изоляция. Основная идея

Тест

Испытываемая системаТестируемый объект

Изоляция. Основная идея

Тест

Испытываемая система

Тестируемый объект

Изоляция. Test Doubles

• Dummies (Пустые объекты)

• Stubs (Заглушки)

• Fakes (Поддельные объекты)

• Spies (Шпионы)

• Mocks (Объекты имитаторы)

Изоляция. Dummies (Пустые объекты)

Изоляция. Stubs (Заглушки)

Изоляция. Fakes (Поддельные объекты)

Изоляция. Spies (Шпионы)

Изоляция. Mock (Объекты имитаторы)

• TypeMock (http://www.typemock.com, Платная)

• RhinoMock (https://github.com/ayende/rhino-mocks, Бесплатная)

• MOQ (http://code.google.com/p/moq/, Бесплатная )

От теории к практике

• Посмотрим на реальном примере как можно применить теорию на практике

• Рассмотрим пример небольшой библиотеки и тесты для неё.

Вредные советы

• Тесты создавать никогда не рано и никогда не поздно

• Если не знаете с чего начать, то начинайте с мест, где есть чёткая, заранее задокументированная логика

• Если вы думаете, что логика тестируемого кода будет сильно изменена. Взвесите все за и против прежде чем писать тесты.

• Хорошей практикой считается создание тестов, на найденный баг.

• Будьте добры к коллегам, потому как тесты в первую очередь адресованы им

Требования к тестам

• Тесты должны быть переносимыми, и не зависть от конфигурации компьютера, на котором они написаны

• Тесты должны быть быстрыми

• Не допускаются в тестах ни условия, ни циклы

• Тест должен быть лаконичным. Если не получается, попробуйте спрятать всю лишнюю обработку в хелперы. Краткость – сестра таланта!

• Тест не должен проверять все возможные ситуации(и тем более позитивные и негативные тесты). Допускается вложение 2-3 ситуаций совпадающих по контексту, который должен следовать из названия теста.

• Следуйте установленным правилам оформления тестов

Правила оформления тестов • Название тестового класса - тестовый класс должен называться

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

• Название тестирующего метода(теста) - должно быть не слишком длинным и должно следовать из контекста, того что вы тестируете. В названии не должно быть слов Test и Scenario. Это и так понятно.

• Тест должен быть построен по ААА шаблону - т.е. должен содержать 3 зоны Arrange-Act-Assert. В зоне Arrange вы настраиваете контекст, в зоне Act выполняете тестируемое действие, в зоне Assert производите различные проверки.

• Тест должен быть качественно отформатирован - в нем не должно быть лишних пустых строк и т.д.

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

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

Спасибо за внимание!