🧪 Тестируем приватные методы: хак или норма? (Спойлер: это запах) Тебе точно знакома ситуация: логика спрятана в приватном методе, а протестировать её «в лоб» нельзя. Первая мысль - рефлексия! Но это как использовать лом для починки часов. Сломаешь больше, чем починишь. Вот почему тестирование приватных методов - это сигнал о проблеме в дизайне класса, и как это исправить правильно 👇 🟢 Шаг 1: Типичный хак через рефлексию (как НЕ делать) import java.lang.reflect.Method; public class Calculator { private int superSecretFormula(int a, int b) { return (a + b) * (a - b); } } // В тесте: Method method = Calculator.class.getDeclaredMethod("superSecretFormula", int.class, int.class); method.setAccessible(true); // Взламываем приватность int result = (int) method.invoke(new Calculator(), 5, 3); ➡️ Проблемы: 🔴 Код теста становится хрупким: переименовал метод — тесты сломались. 🔴 Нарушается инкапсуляция. Тест теперь знает о внутренней кухне класса. 🔴 Это просто некрасиво. Рефлексия — это крик отчаяния. 🟢 Шаг 2: Почему это «запах» кода? Если метод настолько сложный, что его нужно тестировать отдельно — он, скорее всего, делает что-то самостоятельное. Возможно, он: 1. Выполняет несколько задач (нарушает SRP). 2. Содержит логику, которая может пригодиться где-то ещё. 3. Слишком умный для своего класса. ➡️ Частный метод — это деталь реализации. Тестировать нужно публичное поведение, а не приватные детали. 🟢 Шаг 3: Решение №1 — Вынеси логику в отдельный класс ❌Был: public class ReportService { public String generateReport() { // ... подготовка данных String cleaned = cleanData(rawData); // приватный метод // ... формирование отчёта } private String cleanData(String data) { // сложная логика очистки } } ✔️Стал: // Новая публичная единица, которую легко тестировать public class DataCleaner { public String clean(String data) { // та же логика, но теперь она публичная } } // В ReportService: public class ReportService { private final DataCleaner cleaner; public String generateReport() { String cleaned = cleaner.clean(rawData); // ... } } ➡️ Теперь DataCleaner можно и нужно тестировать напрямую. Это чистая архитектура. 🟢 Шаг 4: Решение №2 — Сделай метод package-private (если очень надо) // Было: private void helper() { ... } // Стало (в том же пакете): class Service { void helper() { ... } // без модификатора = виден в пакете } // В тестах (которые лежат в том же test/java/... пакете): @Test void testHelper() { Service service = new Service(); service.helper(); // Доступно! } ➡️ Компромиссный вариант. Логика всё ещё скрыта от внешнего мира, но доступна для тестов. Используй осторожно. 🟢 Шаг 5: Решение №3 — Тестируй через публичный метод Просто протестируй публичный метод, который использует этот приватный. Если покрытие кажется недостаточным — возможно, это повод задуматься: а нужен ли этот тест? Может, приватный метод настолько прост, что не требует отдельного теста? @Test void generateReport_usesCleanDataLogic() { ReportService service = new ReportService(); String report = service.generateReport(); assertThat(report).contains("очищенные данные"); } ➡️ Ты тестируешь результат, а не реализацию. Это сильнее и надёжнее. 🗣️ Запомни: Рефлексия для тестов — как гаечный ключ в микросхеме. Если очень хочется протестировать приватное, значит, твой класс тайно просит, чтобы его разделили. Хороший дизайн рождает лёгкое тестирование.