Добро пожаловать в проект интернет-магазина! Вам предоставлен готовый код бизнес-логики (backend) небольшой E-commerce системы. Код компилируется и работает, но в нём отсутствуют тесты. Ваша задача — спроектировать и написать набор Unit- и интеграционных тестов, настроить непрерывную интеграцию (CI) и оценить качество покрытия кода.
Стек технологий: Java 21, Gradle, JUnit 5, Mockito.
Проект спроектирован по принципу разделения на предметные области (Package by Feature/Domain). Это поможет вам понять, какие виды тестов применять к конкретным пакетам:
- 📦
customerиcatalog— Сущности пользователей, товаров и интерфейс Склада (InventoryService). - 💳
payment— Интерфейс платежного шлюза (PaymentGateway). - 🧮
pricing— Ценообразование (Чистая логика). Здесь лежатDiscountCalculatorиDeliveryCostCalculator. Это идеальные кандидаты для классических Unit-тестов, параметризованных тестов и тестов с подменой времени (Clock). - ⚙️
order— Оркестратор заказов. КлассOrderProcessorсвязывает калькуляторы, банк и склад. Здесь вам потребуются Интеграционные тесты с использованиемMockitoдля создания заглушек (моков) внешних систем.
Вам необходимо покрыть предоставленный код автотестами.
⚠️ ВНИМАНИЕ: О предоставленном примере кода! В репозитории может находиться один демонстрационный тест (например,OrderProcessorTest). Это исключительно пример синтаксиса использования JUnit 5 и Mockito. Вы самостоятельно решаете:
- Какие классы эквивалентности и граничные значения проверять.
- Какие негативные сценарии обрабатывать.
- Как структурировать папку
src/test/java/....- Какие тестовые классы и методы создавать.
Ваши тесты должны демонстрировать понимание следующих техник:
- Обычные модульные тесты (проверка логики).
- Параметризованные тесты (
@ParameterizedTest). - Управление временем в тестах.
- Создание Stub-объектов (заглушек) возвращающих нужные значения (
when(...).thenReturn(...)). - Проверка взаимодействия (Verification) — проверка того, что методы вызывались нужное количество раз (или не вызывались вообще).
Количество тестов не регламентировано — главное продемонстировать соответствующие навыки.
Ваш код должен автоматически собираться и тестироваться при каждом пуше или по требованию вручную. Желательно научиться запускать тесты под разные ОС.
- Создайте в корне репозитория директорию
.github/workflows/. - Добавьте туда YAML-файл (например,
gradle.yml) с конфигурацией GitHub Actions для сборки Java-проекта через Gradle. - Настройте запуск команды
./gradlew test(или./gradlew build). - Получите markdown-ссылку на бейдж статуса сборки (Status Badge) и вставьте её в самое начало этого
README.md.
Подсказка: GitHub может сгенерировать базовый workflow для Gradle автоматически, если вы перейдете во вкладку "Actions" в вашем репозитории.
Написать тесты — половина дела. Нужно понять, какую часть кода они проверяют. Вам необходимо собрать метрики покрытия (Line Coverage, Branch Coverage).
Как это сделать:
- Вариант А (Простой): Использовать встроенные инструменты вашей IDE. В IntelliJ IDEA или Eclipse можно нажать правой кнопкой мыши на папку
testи выбрать «Run with Coverage». Сделайте скриншот полученного отчета и приложите к сдаче работы. - Вариант Б (Не такой простой): Подключить плагин JaCoCo (
id 'jacoco') в файлbuild.gradle. При запуске команды./gradlew test jacocoTestReportон автоматически сгенерирует HTML-отчет, который можно будет найти в папкеbuild/reports/jacoco/test/html/index.html.
- Написать в ЛС, указать ФИО и ссылку на PR в ветку feedback
- Продемонстрировать полученные навыки на защите в формате объяснения принятых решений и ответов на вопросы
(Ниже представлены ссылки, которые помогут вам в выполнении лабораторной работы)
- Официальная документация JUnit 5
- Документация Mockito
- Документация Mockito Junit
- GitHub Actions: Building and testing Java with Gradle
- Java туториал на Metanit
Не полагайтесь только на них, умение гуглить все непонятное — основа решения всех проблем.