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

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

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

Что такое CI/CD в процессе разработки ПО?

Очень распространенный вопрос на собеседовании Junior Java разработчика и trainee (стажера). Даже не с точки зрения знаете ли вы это глубоко или нет, а с точки зрения знакомы ли с этим и насколько. Так что хорошо бы знать ответ, не правда ли?)

Давайте разбираться!

CI – это акроним от Continuous Integration, а CD – это акроним от Continuous Delivery.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

CI/CD – это одна из DevOps-практик. Она также относится и к agile–практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес–требований, на качестве кода и безопасности.

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

В пример приведу всем известный GitHub или BitBucket. Также сюда можно отнести статические анализаторы кода, которые используются при разработке, это Codacy или SonarQube.

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

Здесь в пример можно привести платформы/инструменты для деплоя (развертывания) приложения на какое–нибудь серверное окружение (тот же самый продакшн), например, Jenkins или сервис от Microsoft – Azure. Также к CD можно отнести системы мониторинга уже задеплоенного проекта/приложения – например, DataDog, – сервис для записи логов и отлавливания ошибок на сервере.

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

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

Let's hope!

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

Тестирование ПО. Часть 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. Подписаться