Unit тестирование в Java: от основ до продвинутых техник

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

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

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

В последней версии, JUnit 5, разработчики решили разделить фреймворк на три модуля — видимо, чтобы нам было не скучно:

• JUnit Platform — фундамент, на котором все держится (как ваш код на кофеине).
• JUnit Jupiter — новый API для написания тестов (потому что старый был недостаточно космическим).
• JUnit Vintage — для поддержки старых тестов (потому что кто-то все еще пишет на Java 1.4, да?).

Когда использовать JUnit?

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

Модульное тестирование (Unit Testing) Это как проверка каждого кирпичика перед постройкой замка. Юнит просто создан для этого! Представьте, что у вас есть коробка с деталями Лего — прежде чем собирать космический корабль, неплохо бы убедиться, что каждая деталь не сломана и подходит по размеру. Так же и с кодом — мы проверяем каждый метод, каждый класс по отдельности. Хотите убедиться, что ваш метод правильно считает сумму чисел? Или что валидация пароля не пропускает «123456»? Это все к модульному тестированию!

Интеграционное тестирование А теперь представьте, что детали Лего вы проверили, но нужно убедиться, что они хорошо соединяются друг с другом. В мире кода это означает проверку взаимодействия различных компонентов системы. Как ваш сервис общается с базой данных? Правильно ли контроллер обрабатывает запросы и передает данные? JUnit отлично справляется с такими задачами, особенно в паре с другими инструментами.

End-to-End тестирование Это как финальная проверка собранного космического корабля из Лего — летает ли он так, как задумано? В программировании мы тестируем весь путь пользователя: от входа в систему до выполнения конкретных действий. Юнит, вместе с такими инструментами как Selenium, позволяет автоматизировать эти сценарии. Например, проверить весь процесс регистрации нового пользователя или оформления заказа в интернет-магазине.

Параллельное тестирование Когда у вас много тестов (а их всегда много, поверьте), время их выполнения становится критичным. JUnit 5 позволяет запускать тесты параллельно — это как нанять несколько тестировщиков вместо одного. Особенно полезно при непрерывной интеграции, когда каждый коммит должен проходить все тесты.

Performance Testing Хотя JUnit не создавался специально для тестирования производительности, он может помочь и здесь. Хотите убедиться, что ваш метод выполняется не дольше 100 миллисекунд? Или что загрузка данных укладывается в заданные временные рамки? Юнит предоставляет инструменты и для этого.

И помните, друзья мои, что JUnit — это как швейцарский нож в мире тестирования. Главное — правильно выбрать нужный инструмент для конкретной задачи. А если вы сомневаетесь, использовать ли Юнит для конкретного случая, то ответ почти всегда — да! Лучше написать несовершенный test сегодня, чем идеальный никогда.

Установка и настройка JUnit

Итак, вы решили присоединиться к клубу любителей автоматизированного тестирования? Прекрасно! Теперь давайте разберемся, как впустить фреймворк в свою жизнь (и проект).

Если вы используете Maven (потому что кому нужны эти jar-файлы в 2024 году?), просто добавьте следующую зависимость в ваш pom.xml:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.8.2</version>
    <scope>test</scope>
</dependency>

А для поклонников Gradle (потому что XML — это так 2010) добавьте в build.gradle:

testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.2'

Не забудьте заменить «5.8.2» на актуальную версию, если вдруг Юнит решит порадовать нас новым релизом. И вуаля! Теперь у вас есть Юнит. Используйте его с умом, и да пребудет с вами сила автоматизированного тестирования!

Основные аннотации JUnit

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

@Test — звезда нашего шоу. Поставьте её перед методом, и — бам! — у вас test. Магия, не так ли?

@Test
public void testAddition() {
    assertEquals(2 + 2, 4, "Похоже, математика сломалась. Опять.");
}

@BeforeEach и @AfterEach — верные помощники @Test. Они выполняются до и после каждого теста соответственно. Идеально для подготовки сцены и уборки после представления.

@BeforeEach
void setUp() {
    System.out.println("Поехали! Надеюсь, ничего не взорвется.");
}

@AfterEach
void tearDown() {
    System.out.println("Уф, пронесло. Прибираемся...");
}

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

@BeforeAll
static void initAll() {
    System.out.println("Инициализация. Надеюсь, вы запаслись кофе.");
}

@AfterAll
static void tearDownAll() {
    System.out.println("Всё, расходимся. Ничего интересного больше не будет.");
}

И наконец, @Disabled — волшебная палочка для лентяев. Нужно временно отключить test? Эта аннотация вам в помощь.

@Disabled("Потому что я так сказал!")
@Test
void testComplicatedStuff() {
    // Здесь должен быть сложный тест, но мне лень его писать
}

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

Сравнение JUnit 4 и JUnit 5

Итак, друзья мои, настало время поговорить о борьбе поколений в мире тестирования — Юнит 4 vs JUnit 5. Спойлер: это не совсем «Звездные войны», но тоже весьма увлекательно (по крайней мере, для гиков вроде нас).

JUnit 4, старый добрый дедушка мира тестирования, служил нам верой и правдой много лет. Но время не стоит на месте, и вот на арену выходит JUnit 5, молодой и амбициозный преемник.

Главное отличие? JUnit 5 разделили на три модуля (Platform, Jupiter и Vintage), словно решили устроить вечеринку и пригласить всех друзей. А еще они добавили поддержку лямбда-выражений и Stream API. Видимо, решили, что нам недостаточно головной боли с обычными тестами.

Состав модулей JUnit 5

Вот пример теста на JUnit 4:

@Test
public void oldSchoolTest() {
    Assert.assertEquals("Старая школа все еще в деле", 2 + 2, 4);
}

А вот так выглядит test на Юнит 5:

@Test
void newSchoolTest() {
    assertThat(2 + 2).isEqualTo(4).as("Математика все еще работает");
}

Кроме того, JUnit 5 принес нам такие чудеса, как:

• Вложенные тесты (для тех, кто любит тестировать все до последней запятой)
• Динамические тесты (потому что статические тесты — это так скучно)
• Улучшенная поддержка параметризованных тестов (теперь можно тестировать еще больше комбинаций и сходить с ума еще эффективнее)

Так стоит ли переходить на JUnit 5? Если вы любите новые игрушки и не боитесь изменений — однозначно да. Если же вы консерватор и считаете, что «раньше трава была зеленее» — что ж, JUnit 4 пока никто не отменял. Но помните: прогресс не остановить, и рано или поздно вам придется столкнуться с этим новым, прекрасным миром JUnit 5.

Ключевые особенности JUnit 4 и JUnit 5

Принципы Test-Driven Development (TDD) с JUnit

Test-Driven Development… Звучит как название какого-нибудь инди-рок бэнда, не так ли? Но нет, друзья мои, это методология разработки, которая заставляет нас, программистов, думать о тестах раньше, чем о самом коде. Да-да, вы не ослышались — сначала тесты, потом код. Кажется, что мир перевернулся с ног на голову? Добро пожаловать в мир TDD!

Итак, принципы TDD можно описать тремя простыми шагами (которые вы будете повторять, как мантру):

• Напишите test (который, очевидно, не пройдет).
• Напишите минимальный код, чтобы test прошел.
• Отрефакторите код (и молитесь, чтобы тесты все еще проходили).

Звучит просто? Ха! Давайте посмотрим на это в действии:

// Шаг 1: Пишем тест
@Test
void testAddition() {
    Calculator calc = new Calculator();
    assertEquals(4, calc.add(2, 2), "2 + 2 должно быть 4, если только мы не в мире Оруэлла");
}

// Шаг 2: Минимальный код для прохождения теста
public class Calculator {
    public int add(int a, int b) {
    	return 4; // Да, это работает. Нет, это не правильно.
    }
}

// Шаг 3: Рефакторинг
public class Calculator {
    public int add(int a, int b) {
    	return a + b; // Теперь правильно, и тест все еще проходит!
    }
}

Казалось бы, зачем все эти сложности? Почему бы просто не написать код, а потом тесты? О, мой наивный друг! TDD — это как чистка зубов перед сном: поначалу кажется лишним, но потом ты понимаешь, что это спасает тебя от кучи проблем (и счетов у стоматолога… то есть, багов в продакшене).

TDD помогает нам:

• Лучше продумывать дизайн кода (потому что писать тесты для плохо спроектированного кода — это сущий ад)
• Получать мгновенную обратную связь (ведь лучше узнать о проблеме сейчас, чем в 3 часа ночи, когда прод упал)
• Создавать документацию к коду (потому что кто вообще читает комментарии?)

Так что, дорогие мои, берите фреймворк в руки и вперед, в светлое будущее TDD! И помните: красные тесты — это не баг, это фича (но только до того момента, пока вы не напишете код, чтобы они стали зелеными).

Пишем тесты с нуля: пример на JUnit

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

Для начала создадим наш суперпупер калькулятор:

public class SuperCalculator {
    public int add(int a, int b) {
    	return a + b; // Сложная математика, не пытайтесь это повторить дома!
    }

    public int subtract(int a, int b) {
    	return a - b; // Еще более сложная математика. Возможно, нам понадобится ИИ для этого.
    }
}

Теперь, следуя заветам TDD (и потому что мы мазохисты), напишем тесты до того, как проверим, работает ли наш код:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class SuperCalculatorTest {

    @Test
    void testAddition() {
    	SuperCalculator calc = new SuperCalculator();
    	assertEquals(4, calc.add(2, 2), "2 + 2 должно быть 4. Если нет, то у нас проблемы посерьезнее багов в коде");
    }

    @Test
    void testSubtraction() {
    	SuperCalculator calc = new SuperCalculator();
    	assertEquals(0, calc.subtract(2, 2), "2 - 2 должно быть 0. Если нет, то, возможно, мы случайно изобрели новую математику");
    }

    @Test
    void testAdditionWithNegativeNumbers() {
    	SuperCalculator calc = new SuperCalculator();
    	assertEquals(-1, calc.add(-3, 2), "(-3) + 2 должно быть -1. Если нет, то наш калькулятор, видимо, оптимист");
    }

    @Test
    void testSubtractionWithLargeNumbers() {
    	SuperCalculator calc = new SuperCalculator();
    	assertEquals(1000000, calc.subtract(1000001, 1), "1000001 - 1 должно быть 1000000. Если нет, то наш калькулятор явно не готов к работе с большими данными");
    }
}

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

Но постойте! Мы же забыли про один из главных принципов программирования — «Если что-то работает, добавь еще функций и сломай это»! Давайте добавим метод умножения в наш калькулятор:

public int multiply(int a, int b) {
    return a * b; // Теперь наш калькулятор официально умнее калькулятора из Windows 95
}

И, конечно же, test для него:

@Test
void testMultiplication() {
    SuperCalculator calc = new SuperCalculator();
    assertEquals(6, calc.multiply(2, 3), "2 * 3 должно быть 6. Если нет, то наш калькулятор, видимо, решил стать творческой личностью");
}

Вуаля! Теперь у нас есть полноценный набор тестов для нашего супер-пупер-калькулятора. Конечно, мы могли бы добавить еще тысячу тестов, проверяя каждое возможное число во вселенной, но, давайте будем честны, у нас есть дела поважнее. Например, объяснять менеджеру проекта, почему разработка простого калькулятора заняла целую неделю.

Покрытие кода тестами: когда размер имеет значение

А теперь поговорим о том, что волнует каждого разработчика (и особенно его менеджера) — о покрытии кода тестами. Знаете, это как измерение температуры у пациента — вроде бы простая метрика, но может рассказать о многом!

Что такое покрытие кода? Представьте, что ваш код — это карта подземелья в компьютерной игре. Покрытие кода показывает, какие места этого подземелья вы уже исследовали с помощью тестов. Это процентное соотношение кода, который выполняется во время прогона тестов, к общему объему кода. Проще говоря, это ответ на вопрос «Сколько моего кода реально проверяется тестами?».

Виды покрытия:

• Line Coverage (Покрытие строк) — самый простой вид, показывает, какие строки кода были выполнены
• Branch Coverage (Покрытие ветвей) — проверяет, все ли ветви условных операторов (if-else) были протестированы
• Method Coverage (Покрытие методов) — показывает, какие методы вызывались во время тестирования
• Class Coverage (Покрытие классов) — процент классов, затронутых тестами

Как измерить покрытие? В Java-мире для этого есть отличный инструмент — JaCoCo (Java Code Coverage). Это как счётчик шагов, только для вашего кода. Добавляем в Maven:

Зачем это нужно?

• Качество кода: высокое покрытие тестами обычно (но не всегда!) означает более надёжный код
• Уверенность: чем больше покрытие, тем спокойнее вы спите после релиза
• Документация: тесты показывают, как должен работать код
• Поиск мёртвого кода: низкое покрытие может указать на неиспользуемый код

Мифы о покрытии:

• «100% покрытия = идеальный код» — Ха! Если бы. Можно покрыть весь код тестами и всё равно пропустить критические ошибки.
• «Чем больше покрытие, тем лучше» — Не совсем. Иногда 70% осмысленного покрытия лучше, чем 100% формального.
• «Покрытие тестами — пустая трата времени» — Скажите это себе в 3 часа ночи, когда прод упадёт.

Рекомендации по покрытию:

• Стремитесь к разумному балансу (обычно 70-80% считается хорошим показателем)
• Сначала покрывайте критически важный код
• Не гонитесь за процентами в ущерб качеству тестов
• Регулярно анализируйте отчёты о покрытии
• Включите проверку покрытия в CI/CD pipeline

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

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

Расширенные возможности JUnit 5

Итак, друзья мои, вы уже освоили базовые принципы Юнит и, возможно, думаете: «Ну всё, я теперь гуру тестирования!». Ха! Позвольте вас разочаровать — это только верхушка айсберга. JUnit 5 приготовил для нас еще парочку фокусов в рукаве. Давайте окунемся в мир расширенных возможностей, где тесты пишут сами себя (ну, почти).

Первым делом поговорим о параметризованных тестах. Помните, как вы писали один и тот же test, меняя только входные данные? Забудьте об этом! Теперь у нас есть @ParameterizedTest:

@ParameterizedTest
@ValueSource(ints = {1, 2, 3})
void testNumberIsPositive(int number) {
    assertTrue(number > 0, "Число " + number + " должно быть положительным. Если нет, то мы, видимо, попали в параллельную вселенную.");
}

Красота, не правда ли? Один test, а проверяет сразу несколько значений. Это как шведский стол, только для тестов.

Но @ValueSource — это только верхушка айсберга в мире параметризованных тестов. JUnit 5 припас для нас целый арсенал инструментов для работы с тестовыми данными. Давайте познакомимся с самыми интересными из них!

@CsvSource — когда хочется протестировать пары значений Представьте, что вы тестируете калькулятор и вам нужно проверить множество комбинаций входных данных и ожидаемых результатов. @CsvSource приходит на помощь! Это как электронная таблица Excel, только для тестов. Вы можете определить входные данные и ожидаемый результат прямо в аннотации, и Юнит прогонит test для каждой строки. Удобно, правда?

@MethodSource — для тех, кому мало простых значений А что если наши тестовые данные слишком сложные для простых строк? Что если нам нужно тестировать объекты или сложные структуры данных? @MethodSource позволяет создать отдельный метод, который будет поставлять данные для наших тестов. Это как конвейер на фабрике — метод производит данные, а test их использует.

@CsvFileSource — для тех, кто любит порядок У вас есть огромный набор тестовых данных? Не хотите захламлять код длинными списками значений? @CsvFileSource позволяет хранить тестовые данные в отдельном CSV-файле. Это как хранить свои инструменты не в карманах, а в удобном ящике для инструментов — все организовано и легко поддерживать.

@EnumSource — для любителей перечислений Работаете с enum’ами? @EnumSource позволяет автоматически использовать значения из ваших перечислений в качестве тестовых данных. Это особенно удобно, когда нужно проверить обработку всех возможных статусов или состояний.

@ArgumentsSource — для продвинутых пользователей Когда стандартных источников данных недостаточно, @ArgumentsSource позволяет создать свой собственный поставщик аргументов. Это как написать свой собственный генератор тестовых данных — полная свобода творчества!

Комбинирование разных источников данных А самое интересное начинается, когда вы начинаете комбинировать разные источники данных! Представьте, что у вас есть тест, который использует данные из CSV-файла для основных сценариев, метод-источник для сложных случаев и несколько простых значений из @ValueSource для граничных условий. Это как собирать пазл, где каждый кусочек идеально подходит для своей задачи.

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

P.S. И да, параметризованные тесты — это не просто способ сделать ваш код короче. Это возможность протестировать больше сценариев, найти больше краевых случаев и, в конечном итоге, спать спокойнее ночью, зная, что ваш код проверен со всех сторон!

А теперь приготовьтесь к магии — кастомные расширения с @ExtendWith. Представьте, что вы можете добавить свою собственную логику к выполнению тестов. Звучит как научная фантастика? Добро пожаловать в будущее!

@ExtendWith(MyAwesomeExtension.class)
class MyTest {
    @Test
    void testSomething() {
    	// Здесь магия MyAwesomeExtension уже работает!
    }
}

Конечно, вам нужно будет реализовать этот самый MyAwesomeExtension, но это уже детали. Главное — звучит круто!

И напоследок, вишенка на торте — динамические тесты. Да-да, теперь ваши тесты могут рождаться прямо во время выполнения:

@TestFactory
Stream<DynamicTest> dynamicTestsFromStream() {
    return Stream.of("apple", "banana", "orange")
    	.map(fruit -> dynamicTest("Тест для " + fruit, () -> {
        	assertNotNull(fruit, "Фрукт не должен быть null. Иначе это призрак фрукта?");
        	assertTrue(fruit.length() > 3, "Название фрукта должно быть длиннее 3 букв. Иначе это не фрукт, а ЕДА.");
    	}));
}

Вот так, друзья мои, Юнит 5 превращает написание тестов из рутинной обязанности в настоящее приключение. Теперь вы можете тестировать все, что движется (и даже то, что не движется), с элегантностью танцора и точностью швейцарских часов. Главное — не увлекитесь и не начните тестировать тесты для тестов. Хотя… почему бы и нет?

Моки и стабы: искусство притворства в тестировании

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

Что такое мок (Mock)? Мок — это как профессиональный актёр дублер. Он не только выглядит как настоящий объект, но и умеет проверять, как с ним взаимодействуют. Например, если ваш код должен отправить email, вы же не будете ради теста спамить реальные почтовые ящики? Вместо этого создаётся мок почтового сервиса, который просто делает вид, что отправляет письма, а заодно записывает, сколько раз его просили это сделать.

Что такое стаб (Stub)? Стаб — это как картонная декорация. Он проще мока и просто возвращает заранее подготовленные данные. Не следит за вызовами, не проверяет параметры — просто тупо отвечает то, что мы ему сказали. Идеально подходит, когда нам надо просто получить какие-то данные, например, из базы данных или внешнего API.

Когда что использовать?

• Используйте мок, когда важно проверить поведение:
  • Сколько раз был вызван метод?
  • С какими параметрами?
  • В каком порядке происходили вызовы?
• Используйте стаб, когда важен только результат:
  • Нужны тестовые данные
  • Не важно, как именно их получили
  • Хотите избежать реальных вызовов базы данных или API

Золотые правила использования моков и стабов:

• «Не мокайте то, чего не существует» — сначала напишите интерфейс, потом мок
• «Не мокайте простые объекты» — создавайте реальные String, Integer и прочие простые объекты
• «Не увлекайтесь» — чем больше моков, тем дальше тесты от реальности
• «Держите моки простыми» — сложный мок = сложный test = сложные проблемы

Типичные сценарии использования:

• База данных: стаб для получения тестовых данных
• Внешние API: мок для проверки правильности отправки запросов
• Файловая система: стаб для имитации чтения/записи файлов
• Email-сервис: мок для проверки отправки писем
• Платёжные системы: обязательно мок! Не хотите же вы случайно списать реальные деньги?

Подводные камни:

• Слишком много моков делают тесты хрупкими
• Сложные моки сложно поддерживать
• Можно случайно протестировать сам мок вместо реального кода
• Излишнее мокирование может пропустить реальные проблемы интеграции

Признаки того, что вы слишком увлеклись моками:

• На настройку моков уходит больше кода, чем на сам test
• Вы мокаете методы, которые ещё не написали
• Тесты падают при любом рефакторинге
• Вы начинаете писать код под моки, а не наоборот

И помните главное правило: моки и стабы — это специи в блюде под названием «тестирование». Добавляйте их по вкусу, но не переборщите, иначе испортите всё блюдо. Используйте их там, где это действительно нужно, а не просто потому, что можете!

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

Мокирование зависимостей с Mockito: когда реальность — не вариант

А теперь, друзья мои, давайте поговорим о мокировании — этом волшебном искусстве создания фальшивых объектов. Знаете, иногда наш код зависит от компонентов, которые работают с базой данных, внешними API или, что еще хуже, с той легендарной legacy-системой, которую никто не трогал с 2005 года. И вот тут на сцену выходит Mockito — наш спаситель в мире изоляции тестов!

Для начала добавим Mockito в наш проект (потому что без него все последующее будет просто мечтами):

xml

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>5.3.1</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>5.3.1</version>
    <scope>test</scope>
</dependency>

Теперь давайте представим, что у нас есть сервис, который работает с базой данных:

java

public class UserService {
    private final UserRepository repository;
    
    public UserService(UserRepository repository) {
        this.repository = repository;
    }
    
    public User findUserById(Long id) {
        return repository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("Пользователь не найден. " +
                "Возможно, он ушёл в другой микросервис?"));
    }
}

И вот как мы можем протестировать его, не поднимая настоящую базу данных:

java

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    
    @Mock
    private UserRepository repository; // Создаём мок-объект репозитория
    
    @InjectMocks
    private UserService userService; // Mockito внедрит мок в сервис
    
    @Test
    void shouldFindUserById() {
        // Подготовка
        User expectedUser = new User(1L, "Василий Тестов");
        when(repository.findById(1L))
            .thenReturn(Optional.of(expectedUser)); // Говорим моку, что вернуть
        
        // Действие
        User actualUser = userService.findUserById(1L);
        
        // Проверка
        assertEquals(expectedUser, actualUser, 
            "Мок должен вернуть нашего тестового пользователя, " +
            "если только он не обрёл самосознание");
        
        verify(repository).findById(1L); // Проверяем, что мок был вызван
    }
    
    @Test
    void shouldThrowExceptionWhenUserNotFound() {
        // Подготовка
        when(repository.findById(anyLong()))
            .thenReturn(Optional.empty()); // Мок будет возвращать пустой Optional
        
        // Действие и проверка
        assertThrows(UserNotFoundException.class,
            () -> userService.findUserById(999L),
            "Должны получить исключение, когда пользователя нет");
    }
}

А для тех, кто любит усложнять себе жизнь, Mockito предлагает ArgumentCaptor — эдакий шпион для аргументов методов:

java

@Test
void shouldCaptureArgumentsPassedToMock() {
    // Создаём захватчик аргументов
    ArgumentCaptor<Long> idCaptor = ArgumentCaptor.forClass(Long.class);
    
    userService.findUserById(42L);
    
    // Проверяем, что в репозиторий передали именно то, что нужно
    verify(repository).findById(idCaptor.capture());
    assertEquals(42L, idCaptor.getValue(),
        "Если сюда попало другое значение, то у нас проблемы с пространством-временем");
}

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

Часто встречающиеся ошибки при работе с JUnit и их решения

Ошибки… Эти коварные создания, которые превращают наш код в сущий ад и заставляют нас задуматься о смене профессии. Но не спешите бросать все и уходить в монастырь — давайте разберемся с самыми популярными «граблями» при работе с JUnit.

• «NoClassDefFoundError: org/junit/platform/commons/PreconditionViolationException» Поздравляю, вы попали в классическую ловушку несовместимости версий! Проверьте, что все ваши Юнит зависимости одной версии. Maven и Gradle иногда ведут себя как капризные дети и приносят в проект разные версии библиотек. Решение: В pom.xml добавьте.
• «java.lang.Exception: No runnable methods» О, эта ошибка — настоящий праздник для любителей «забыть что-нибудь важное». Скорее всего, вы забыли добавить аннотацию @Test к вашим тестовым методам. Или, что еще «веселее», вы используете JUnit 5, а IDE настроена на JUnit 4. Решение: Проверьте, что у всех тестовых методов есть аннотация @Test, и что вы импортируете правильный пакет (org.junit.jupiter.api.Test для JUnit 5)
• «Test class should have exactly one public constructor» Ах, как я люблю эту ошибку! Она появляется, когда вы решили, что вашему тестовому классу нужен особенный конструктор. Спойлер: ему не нужен. Решение: Удалите все конструкторы из тестового класса. Юнит сам создаст экземпляр класса для каждого теста
• «Tests in error: initializationError» Эта ошибка — как незваный гость на вечеринке. Она может появиться по множеству причин, но чаще всего это проблемы с настройкой тестового окружения. Решение: Проверьте, что ваш тестовый класс публичный, не абстрактный и находится в правильном пакете.

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

Заключение

Итак, дорогие мои кодо-воины, мы прошли долгий путь от простых assert’ов до хитроумных параметризованных тестов. Надеюсь, теперь вы вооружены знаниями о JUnit и готовы тестировать всё, что движется (и даже то, что не движется).

Помните, что Юнит — это не просто инструмент, это образ жизни. Это как чистка зубов для программиста — поначалу кажется лишним, но потом ты понимаешь, что это спасает тебя от множества проблем.

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

И напоследок, помните главное правило тестирования: если ваши тесты не находят ошибок, значит, вы недостаточно стараетесь. Удачи в ваших тестовых приключениях, и да пребудет с вами сила assert’а!