Тестирование ПО. Часть 1.

Тестирование – это очень важный процесс в разработке ПО. Серьезно, настоящий разработчик должен уметь не только писать код, решая задачу, которую хочет бизнес, но и тестировать свое решение.

Тестирование в разработке – это, Иными словами, проверка правильности работы нашей программы в тех или иных ситуациях.

Видов тестирования, методик, разделов существует очень много, все они углубленно изучаются отдельными специалистами – тестировщиками (ручными или авто). Я же остановлюсь непосредственно на основных видах тестирования, которые используем мы – Java разработчики.

Тут все просто – будем опираться на пирамиду тестирования Майка Кона (на картинке).

Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме.
Данные тесты покрывают маленькие кусочки кода и весьма легковесные, не кушающие много ресурсов (под ресурсами я имею виду оперативную память и время).

Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее.

Как пример интеграционных тестов можно рассмотреть соединение с базой данных и проверку правильной отработки методов, работающих с ней.

UI — тесты, которые проверяют работу пользовательского интерфейса. Они затрагивают логику на всех уровнях приложения, из-за чего их еще называют сквозными. Их как правило в разы меньше, так они наиболее тяжеловесны и должны проверять самые необходимые (используемые) пути.

На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Что вернет метод, если value = null?

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Тестирование ПО. Часть 2.1. Ключевые понятия юнит–тестирования.

Покрытие тестов (Code Coverage) — одна из главных оценок качества тестирования приложения. Это процент кода, который был покрыт тестами (0–100%).

На практике многие гонятся за этим процентом, с чем я не согласен, так как начинается навешивание тестов там, где они не нужны. Например, у нас в сервисе есть стандартные CRUD (create/get/update/delete) операции без дополнительной логики. Эти методы — сугубо посредники, делегирующие работу слою, работающему с репозиторием (для взаимодействия с базой данных). В данной ситуации нам нечего тестировать: разве то, что вызывает ли данный метод — метод из дао, но это не серьёзно 😅

TDD (Test–driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Основная цель TDD – сделать код более понятным, простым и без ошибок.

Подход состоит из таких составляющих:

– Пишем наш тест.
– Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть 😄).
– Добавляем код, который должен удовлетворить данный тест (запускаем тест).
– Выполняем рефакторинг кода.
– That's it.

Продолжим дальше говорить о других ключевых понятиях.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Тестирование ПО. Часть 2.2. Ключевые понятия тестирования.

BDD (Behavior–driven development) — разработка через поведение. Это подход основан на TDD. Если говорить точнее, он использует написанные понятным языком примеры (как правило на английском), которые иллюстрируют поведение системы для всех, кто участвует в разработке. Не будем углубляться в данный термин, так как он в основном затрагивает тестировщиков и бизнес-аналитиков.

Тестовый сценарий (Test Case) — сценарий, описывающий шаги, конкретные условия и параметры, необходимые для проверки реализации тестируемого кода.

Чтобы обеспечить модульность теста, нужно нужно изолироваться от других слоев приложения. Сделать это можно помощью заглушек, моков, и шпионов.

Мок (Mock) — объекты, которые настраиваются (обычно специфично для каждого теста) и позволяют задать ожидаемые ответы методов, которые мы хотим получить. Проверки соответствия ожиданиям проводятся через вызовы к Mock–объектам.

Заглушки (Stub) — обеспечивают жестко зашитый ответ на вызовы во время тестирования.

Также они могут сохранять в себе информацию о вызове (например, параметры или количество этих вызовов). Такие иногда называют своим термином — шпион (Spy).

Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за стаба, а вот из-за мока может.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

❔ Вопрос с собеседования

Можно ли использовать private или protected переменные в Java interface?

Ответ: В Java переменные, объявленные с модификаторами private или protected, не могут быть использованы непосредственно в интерфейсах (interfaces).

✅ JavaStart. Подписаться

Тестирование ПО. Часть 3. JUnit тестирование.

Для Java доступно несколько сред тестирования (фреймворков). Самый популярный из них — JUnit. Используется для модульных тестов. Библиотека JUnit подключается к системе сборки приложений, которой пользуется разработчик, — Maven или Gradle.

JUnit тест представляет собой метод, содержащийся в классе, который используется только для тестирования. Класс, как правило, называется так же, как и класс, который он тестирует с +Test в конце. Например, CarService → CarServiceTest. По сути этот класс и называется тестовым.

В тестовом классе сам тестовый метод обязательно помечается аннотацией @Test, без нее мы просто не сможем запустить наш тест.

Рассмотрим примитивные юнит тесты для понимания.

Создадим некий тестовый класс PersonServiceTest.

В первом тестовом методе на картинке мы создаем объект типа Person, сетим ему имя (в String поле firstName) и просто проверяем, что это поле теперь равно “Stephen”.

Мы используем метод .assertEquals(x, y) из пакета org.junit* ,
где x – это значение, которое мы ожидаем, y – это реальное значение (в нашем случае реальное значение поля firstName).

Во втором тестовом методе на картинке создаем объект типа Person, но уже не сетим никакого состояния ему (не сетим какие-либо поля – firstName или, например, secondName, неважно), но проверяем, что созданный объект существует в памяти, используя один из методов фреймворка JUnit - .assertNotNull(x),
где x – это проверяемый аргумент любого типа (наследуется от класса Object).

Идея такая. В целом, ничего сложного)

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Тестирование ПО. Часть 4. Базовые аннотации в Java тестировании.

Пройдёмся по базовым аннотациям процесса тестирования.
Хорошо бы знать основные аннотации и для чего они используются, так как такой вопрос может возникнуть на собеседовании на Junior Java разработчика или стажера. Хороший разраб тот, кто тестирует свой код!

@Test — определение данного метода в качестве тестируемого (метод, помеченный данной аннотацией и есть тест).

@Before — помечается метод, который будет выполняться перед каждым тестом. Например, заполнение тестовых данных класса, чтение входных данных.

@After — ставится над методом, который будет вызывать после каждого теста (чистка данных, восстановление дефолтных значений).

@BeforeClass — ставится над методом, вызывается лишь однажды перед всеми тестами для данного класса. Используется для выполнения более тяжелых операций, как например подъем тестовой БД.

@AfterClass — исполняется один раз для данного класса, но после всех тестов (например, для очистки постоянных ресурсов или отключения от БД).

@Ignore — отмечает, что метод ниже отключен и будет игнорироваться при общей прогонке тестов. Используется в разных случаях, например, если изменили базовый метод и не успели переделать под него тест. В таких случаях ещё желательно добавить описание — @Ignore("Some description").

@Test(expected = Exception.class) – для отрицательных тестов. Ожидается, что метод выкинет некоторое исключение.

@Test(timeout=100) — проверяет, что метод исполняется не более чем 100 миллисекунд.

@Mock — используется над полем в тестовом классе для задания какого-либо объекта моком (это не из JUnit библиотеки, а из Mockito, о нем позже), поведение мока задаётся в конкретной ситуации в методе теста.

@RunWith(MockitoJUnitRunner.class) — метод ставится над классом. Он и является кнопкой для прогона тестов в нем. Runner-ы могут быть различными: например, есть такие: MockitoJUnitRunner, JUnitPlatform, SpringRunner и т. д.).

В JUnit 5 аннотацию @RunWith заменили более мощной аннотацией @ExtendWith.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Тестирование ПО. Часть 5.1. Mock тестирование.

Для Java доступно несколько сред тестирования (фреймворков). Второй по популярности после JUnit — это Mockito. Используется разработчиками для юнит и интеграционных тестов при разработке приложений.

Одним из примеров интеграционного теста является ситуация, когда наше приложение взаимодействует с каким-нибудь сторонним сервисом, за работу которого отвечаем не мы, а, например, другая команда, но при этом нам нужно как бы сэмулировать поведение этого стороннего сервиса в нашем тесте!

Вторым примером можно считать интеграцию нашего приложения с базой данных, когда мы эмитируем получение какого-то объекта из базы.

Mockito легко и быстро подменяет реальные объекты программы «пустышками». Такие фиктивные объекты называют «моками» (mock — подражать).
Библиотека Mockito подключается к системе сборки приложений, которой пользуется разработчик, — Maven или Gradle.

При мок–тестировании создаются объекты–имитаторы (моки), которые реализуют поведение реальной подсистемы. Моки используются как замена зависимостей.

Иными словами, помощью Mockito разработчик создает имитатор — мок, указывает библиотеке, что делать при вызове определенных методов, а затем использует экземпляр имитатора в своем тесте вместо реального объекта.

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

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Тестирование ПО. Часть 5.2. Mock тестирование.

Использование when().thenReturn().

Моки могут возвращать различные значения в зависимости от аргументов, переданных в метод.

Цепочка методов when(…).thenReturn(…) используется для указания возвращаемого значения для вызова метода с заранее заданными параметрами.

Для возврата значений также можно использовать такие методы, как anyString() или anyInt().

Рассмотрим Mock тестирование снова на примитивном примере для лучшего понимания основной идеи!

Создаем тестовый класс MyClassTest.
Мы будем тестировать некий метод calculateZ(), который находится классе MyClass. Этот метод, предположим, просто суммирует два числа типа int.

Но эти самые два числа типа int возвращаются у нас из класса MyService, в котором есть 2 метода - calculateX() и calculateY(int number).

И так, на 8 строке мы мокаем класс MyService, в котором есть 2 метода, которые возвращают числа типа int. Иными словами делаем из этого класса заглушку.

Далее с 10 по 16 строки делаем необходимые действия, чтобы мы смогли запустить тестовый класс и все у нас отработало. На 11 строке инжектим (внедряем) все моки в наш тестируемый класс с методом calculateZ(). А на 14 строке мы инициализируем все наши моки. Инициализироваться они будут перед запуском тестового метода.

Сам тестовый метод у нас на 19 строке, помеченный аннотацией @Test.

И вот мы дошли до самой подмены возвращаемых значений! На строке 20 через цепочку вызовов методов when(...).thenReturn(...) у конкретного мока класса MyService и его метода calculateX() мы возвращаем подменное значение равное 1.

На 21 строке подменяем возвращаемое значение метода calculateY(int number) двойкой.

И наконец на 23 строке вызываем наш тестируемый метод calculateZ(), который находится классе MyClass и присваиваем результату переменную int result.

На 25 строке делаем проверку о том, что ожидаемый результат 3 совпадает с фактическим (1 + 2 = 3).

А на 26 строке верифицируем, что наш тестируемый метод был вызван только 1 раз.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Тестирование ПО. Часть 6. Итоги.

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

Когда у нас есть юнит и интеграционные тесты, написанные для большинства классов нашего приложения, мы можем уверенно провести рефакторинг. И самое главное — это помогает нам легко находить ошибки во время разработки.

Представьте, что вы, как начинающий Java backend разработчик, пришли на коммерческий проект, допустим, в банк и вам поручили сделать небольшое изменение в программе. Так вот если та часть приложения, в которой вы будете вносить изменения, покрыта тестами, то вы с легкостью поймете, если что-то поломали в бизнес логике.

Это касается не только начинающих Java разработчиков, но и миддлов и синьоров! Когда им ставят задачу внести какое-то серьезное изменение в уже работающий функционал, то с помощью написанных в проекте тестов можно легко сориентироваться, как это должно работать на самом деле и понять, как именно новый функционал будет затрагивать уже написанный функционал.

Представьте себе, как много сил мы потратим при изменении дизайна программного обеспечения с сотнями файлов классов без тестирования!

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Git. Часть 1. Что такое Git?

Git — это распределенная система контроля версий, которая позволяет сразу нескольким разработчикам сохранять и отслеживать изменения в файлах проекта.

Git называется распределенной системой контроля версий, поскольку имеет хранилище данных (репозиторий) не только на сервере, но и локально на тех машинах, которыми пользуются разработчики. От других систем Git отличается особым подходом к обработке информации: он не записывает отдельно внесенные правки, а делает подробный снимок проекта в момент сохранения, то есть фиксирует состояние каждого файла, и создает ссылку на эту версию.

Для чего нужен Git?

В основном Git применяют при работе с исходным кодом, но его можно использовать для любых файлов на усмотрение пользователя. К помощи Git часто прибегают при переводе книг, когда нужно сопоставить выполненную работу с оригиналом, дизайнеры тоже нередко пользуются его возможностями. Он позволяет анализировать изменения, просматривать их историю, сравнивать разные версии одних и тех же файлов.

Что касается создания приложений и сайтов, то здесь Git — обязательный и незаменимый инструмент. Часто бывает так, что внесенное в код исправление рушит работающие части проекта, и даже после отмены этого исправления ситуация не улучшается. Решение — Git. Он защищает ваш проект от подобных неожиданностей и исключает возможность случайного удаления правок или файлов.

Благодаря Git можно быстро откатить проект до рабочего состояния при возникновении ошибок. Вам не потребуется выискивать проблемы, которые повлекло за собой добавление изменений, ведь в любой момент можно вернуться к одной из старых версий. Такая система нужна, чтобы люди, участвующие в разработке, могли беспрепятственно «копаться» в коде, не боясь навредить чужим правкам или работе проекта в целом.

С помощью Git можно поддерживать рабочую версию и параллельно создавать новые, одной командой сливать их воедино или разделять. Этот инструмент ускоряет процесс разработки и делает его более эффективным.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться