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

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

2. Виды тестов • Модульные • Тестируется функционал ограниченной части кода (минимум – класса) • Тесты изолированы от других частей кода (не зависят от изменений в других классах) • Интеграционные • Тестируется взаимодействие между модулями • Системные • Тестируется система в целом

3. Модульные тесты • Определение. МТ – некоторый код (обычно метод), который вызывает другой участок кода (unit of code) с целью проверить некоторую гипотезу. Если гипотеза не подтверждается, тест считается неуспешным (fail). • Unit, как правило, метод или функция • Технически корректное определение мало помогает в написании МТ

4. Модульные тесты • Если писать МТ неправильно – пользы от них не будет (кроме как набирания опыта в написании правильных) • Необходимо определить признаки «хороших», правильных МТ • Тестовое приложение с одной кнопкой – пример МТ, который писал каждый

5. Свойства МТ • Полностью автоматизирован и воспроизводим (automated and repeatable) • Простой в реализации • Может использоваться достаточно долго • Любой способен запустить его и увидеть результат • Может быть запущен «одной кнопкой» (не требует конфигурирования) • Должен исполняться быстро (весь пакет тестов не должен выполняться более 1-2 минут)

6. Недостатки интеграционных тестов • Требуют конфигурирования • Требуют специальных знаний для запуска и конфигурирования (=> не все могут запускать их) • Выполняются дольше (=> не могут выполняться часто) • Тестируют большой кусок системы за один раз (труднее локализовать ошибку и ответственного за исправление)

7. Требования к хорошему МТ • Trustworthiness (к тесту должно быть доверие) • Переписывать/удалять устаревшие • Не помещать в тест много логики • Тестировать одну вещь за один тест • Хорошее покрытие кода тестами • Maintainability (тест должно быть легко поддерживать) • Не тестируются закрытые методы • МТ должны быть изолированы • Readability (тест должен быть понятным) • Понятные названия (можно на русском) • Тесты документируют код • Осмысленные assert

8. Пример МТ с использованием NUnit • Тестируемый класс

9. Пример МТ с использованием NUnit • Методы SetUpи TearDown

10. Пример МТ с использованием NUnit • Тривиальные тесты

11. Пример МТ с использованием NUnit • Тривиальные тесты

12. Пример МТ с использованием NUnit

13. Зависимости (Dependencies) • Зависимости препятствуют написанию МТ (test-inhibiting design) • Приходится избавляться от прямых зависимостей Предположим, выполнение метода требует чтения конфигурационного файла:

14. Inversion of Control

15. Inversion of Control • Выделяем работу с внешним ресурсом в отдельный класс

16. Inversion of Control • Выделяем интерфейс

17. Inversion of Control • Пишем заглушку

18. Dependency Injection • Dependency Injection (внедрение зависимости) – способ разрешения зависимостей в коде • Получить интерфейс через конструктор и сохранить его в поле класса (constructor injection) • Открыть интерфейс как свойство и устанавливать его перед вызовом метода (property injection) • Получать интерфейс в момент вызова метода: • В виде входного параметра (parameter injection) • С помощью фабрики • С помощью внутреннего метода, работающего в качестве фабрики (local factory method или Extract-and-Override) • Комбинируя эти подходы

19. Внедрение через конструктор • Слишком много конструкторов и параметров • Не управляем временем жизни объекта • Внедрение через свойство • Может быть нарушение инкапсуляции

20. Dependency Injection • Использование фабрики • Одна фабрика возвращает настоящий объект в рабочем коде, или fake в тестовом • Используются две фабрики: настоящая и для тестового кода (создаётся фейк для самой фабрики)

21. Dependency Injection • Extract-and-Override • В тестируемом классе создаём виртуальный метод-фабрику • Наследуемся от класса и перегружаем метод-фабрику, чтобы он возвращал фейк • Тестируем дочерний класс

22. Dependency Injection • Extract-and-Override для создания заглушек

23. DI-фреймворки (IoCконтейнеры) • IoCконтейнеры для .NET • Unity Application Block 2.0 • Spring.NET • StructureMap • CastleProject • Seasar • Winter.NET • Ninject

24. DI-фреймворки (IoCконтейнеры) • Unity Application Block

25. DI-фреймворки (IoCконтейнеры) • Unity Application Block

26. Fake-объекты в МТ • Модульное тестирование: • State-Based Testing (a.k.a. State Verification) • Корректность определяется проверкой состояния тестируемого объекта после выполнения метода • Interaction Testing • Корректность определяется тем, как объект взаимодействует с другими объектами во время теста (пример с проверкой системы полива) • В некоторых случаяхтест может быть эквивалентно выражен либо как State-Based тест, либо как Interaction тест

27. Fake-объекты в МТ • Fake-объекты: • Mocks (моки) • Stubs (заглушки)

28. Mock-объекты в МТ • Пример ручного создания мока

29. Mock-объекты в МТ • Пример ручного создания мока

30. Mock-объекты в МТ • Пример ручного создания мока

31. Fake-объекты в МТ • Советы • Можно использовать несколько заглушек в одном тесте • Не стоит использовать больше одного мока в одном тесте • Нужно тестировать контракт класса, не пытаться тестировать ожидаемую внутреннюю реализацию

32. Fake-объекты в МТ • Проблемы с Fake-объектами, созданными вручную • На их написание требуется время • Если в классах-зависимостях много методов, писать моки и заглушки становится трудно • Написанные фейки для одного теста трудно повторно использовать для других

33. Isolation фреймворки • Существующие .NET Isolation фреймворки(a.k.a. mock-object фреймворки) • FakeItEasy • Microsoft Moles • Moq • NMock • NSubstitute • POCMock • Rhino Mocks • Typemock

34. Isolation фреймворки Ручное создание мока С помощью Rhino Mocks (стиль record-and-replay)

35. Isolation фреймворки Ручное создание мока С помощью Rhino Mocks (стиль arrange-act-assert)

36. Isolation фреймворки Ручное создание мока С помощью Moq

37. Isolation фреймворки • Ограничения Isolation фреймворков • Фейки можно создавать только для виртуальных нестатических методов (кроме Moles иTypeMock)

38. Ссылки • Roy Osherove. The Art of Unit Testing