4. Unit Тестирование (JUnit, Mockito, Factory) Flashcards
Какие виды тестирования бывают?
1) Unit тесты - тестирование одного юнита нашей системы (Service слой). Отвечают программисты
2) Интеграционные тесты - например тестирование интеграции БД в нашу систему. Сквозное тестирование от слоя View до DAO. Пишут прогеры или тестировщики
3) Нагрузочное тестирование - например интеграционное * 1000 rps (request per second)
4) Ручное тестирование - прохождение по тест кейсам. Тестировщики
Что такое unit тестирование?
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Для чего нужна библиотека Mockito?
Mockito — фреймворк для работы с заглушками.
Как известно, при тестировании кода (прежде всего юнит-тестировании, но не только) тестируемому элементу часто требуется предоставить экземпляры классов, которыми он должен пользоваться при работе. При этом часто они не должны быть полнофункциональными — наоборот, от них требуется вести себя жёстко заданным образом, так, чтобы их поведение было простым и полностью предсказуемым. Они и называются заглушками (stub). Чтобы их получить, можно создавать альтернативные тестовые реализации интерфейсов, наследовать нужные классы с переопределением функционала и так далее, но всё это достаточно неудобно, избыточно и чревато ошибками. Более удобное во всех смыслах решение — специализированные фреймворки для создания заглушек. Одним из таковых (и, пожалуй, самым известным для Java) и является Mockito.
Mockito позволяет создать одной строчкой кода так называемый mock (что-то вроде основы для нужной заглушки) любого класса. Для такого mock сразу после создания характерно некое поведение по умолчанию (все методы возвращают заранее известные значения — обычно это null либо 0). Можно переопределить это поведение желаемым образом, проконтролировать с нужной степенью детальности обращения к ним так далее. В результате mock и становится заглушкой с требуемыми свойствами.
mock можно создать и для тех классов, новый экземпляр которых вообще-то так просто не создашь, в частности, классов с исключительно приватными конструкторами типа синглтонов и утилитных классов, а при минимальной настройке фреймворка — и перечислений (enums).
Что такое инъекция зависимости и как она помогает в тестировании?
Согласно принципам, класс должен полностью сосредоточиться на выполнении своих обязанностей, а не на создании объектов, необходимых для выполнения этих обязанностей. И именно здесь начинается внедрение зависимостей: она предоставляет классу требуемые объекты.
В Java, прежде чем мы сможем использовать методы других классов, нам необходимо для начала создать экземпляры этого класса (то есть класс А должен создать экземпляр класса В).
Таким образом, передавая задачу создания объекта чему-то другому и прямое использование этой зависимости называется внедрением зависимостей.
Существует три основных типа внедрения зависимостей:
constructor injection: все зависимости передаются через конструктор класса.
setter injection: разработчик добавляет setter-метод, с помощью которого инжектор внедряет зависимость
interface injection: зависимость предоставляет инжектору метод, с помощью которого инжектор передаст зависимость. Разработчики должны реализовать интерфейс, предоставляющий setter-метод, который принимает зависимости
Внедрение зависимостей ответственно за:
Создание объектов;
Представление о том, какие классы требуются этим объектам;
И предоставление зависимостей этим объектам.
Если есть какие-либо изменения в объектах, то DI смотрит на него, и он не должен относиться к классу с использованием этих объектов.
Таким образом, если объекты будут меняться в будущем, тогда ответственность DI заключается в предоставлении соответствующих объектов классу.
Инверсия управления — концепция, лежащая в основе внедрения зависимости
Это означает, что класс не должен конфигурировать свои зависимости статистически, а должен быть сконфигурирован другим классом извне.
Это пятый принцип S.O.L.I.D из пяти основных принципов объектно-ориентированного программирования и разработки от дяди Боба, в котором говорится, что класс должен зависеть от абстракции, а не от чего-то конкретного (простыми словами, жестко закодированного).
Преимущества использования внедрения зависимостей
Помогает в модульном тестировании
Количество шаблонного кода сокращается, поскольку инициализация зависимостей выполняется компонентом инжектора;
Расширение приложения становится еще проще;
Помогает уменьшить связность кода, что важно при разработке приложений.
Недостатки использования внедрения зависимостей
Это несколько сложновато для изучения, а чрезмерное использование может привести к проблемам управления или другим проблемам.
Многие возможные ошибки из процесса компиляции перемещаются в процесс выполнения программы.
Внедрения зависимостей во фреймворках реализовано с помощью рефлексии или динамического программирования. Это может помешать использованию автоматизации разработки с помощью IDE, например, будет сложно воспользоваться функциями «найти ссылки», «показать иерархию вызовов» и будет сложно заниматься безопасно рефакторингом.
Тем не менее вы вполне можете реализовать внедрение зависимостей самостоятельно без использования сторонних библиотек и фреймворков или используя их.
Библиотеки и фреймворки, реализующие внедрение зависимостей:
- Spring (Java)
- Google Guice (Java)
- http://square.github.io/dagger/ (Java and Android)
- Castle Windsor (.NET)
- Unity(.NET)
