Как тестировать класс с приватными методами, полями и внутренними классами в Java?

Почему не стоит тестировать приватные методы напрямую

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

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

В вашем примере публичный метод processOrder() вызывает все приватные методы внутри себя. Значит, вы можете протестировать их косвенно, проверяя результат работы публичного метода. Вот как это сделать:

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

class OrderProcessorTest {
    
    @Test
    void processOrder_shouldCalculateTotalWithTax() {
        // Arrange
        OrderProcessor processor = new OrderProcessor();
        Order order = new Order();
        order.addItem(new Item("Book", 100.0));
        order.addItem(new Item("Pen", 50.0));
        
        // Act
        double result = processor.processOrder(order);
        
        // Assert
        // subtotal = 150.0, tax = 20%, total = 180.0
        assertEquals(180.0, result, 0.001);
    }
    
    @Test
    void processOrder_shouldThrowExceptionForNullOrder() {
        OrderProcessor processor = new OrderProcessor();
        
        assertThrows(IllegalArgumentException.class, 
            () -> processor.processOrder(null));
    }
    
    @Test
    void processOrder_shouldThrowExceptionForEmptyOrder() {
        OrderProcessor processor = new OrderProcessor();
        Order emptyOrder = new Order();
        
        assertThrows(IllegalArgumentException.class, 
            () -> processor.processOrder(emptyOrder));
    }
    
    @Test
    void processOrder_shouldAddOrderToProcessedList() {
        OrderProcessor processor = new OrderProcessor();
        Order order = new Order();
        order.addItem(new Item("Laptop", 1000.0));
        
        processor.processOrder(order);
        
        assertEquals(1, processor.getProcessedOrders().size());
        assertTrue(processor.getProcessedOrders().contains(order));
    }
}

Когда reflection может быть оправдан

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

import java.lang.reflect.Field;
import java.lang.reflect.Method;

@Test
void testPrivateMethodWithReflection() throws Exception {
    OrderProcessor processor = new OrderProcessor();
    
    // Доступ к приватному полю
    Field ordersField = OrderProcessor.class.getDeclaredField("orders");
    ordersField.setAccessible(true);
    List<Order> orders = (List<Order>) ordersField.get(processor);
    assertTrue(orders.isEmpty());
    
    // Вызов приватного метода
    Method method = OrderProcessor.class.getDeclaredMethod("applyTax", double.class);
    method.setAccessible(true);
    double result = (double) method.invoke(processor, 100.0);
    assertEquals(120.0, result, 0.001);
}

Что делать с внутренними классами?

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

// Выносим валидатор в отдельный класс
public class OrderValidator {
    public boolean isValid(Order order) {
        return order != null && order.getItems().size() > 0;
    }
}

// Используем его через композицию
public class OrderProcessor {
    private OrderValidator validator = new OrderValidator();
    
    private void validateOrder(Order order) {
        if (!validator.isValid(order)) {
            throw new IllegalArgumentException("Invalid order");
        }
    }
}

// Теперь легко тестировать
class OrderValidatorTest {
    @Test
    void isValid_shouldReturnFalseForNullOrder() {
        OrderValidator validator = new OrderValidator();
        assertFalse(validator.isValid(null));
    }
}

Рекомендации

• Рефакторинг — если приватный метод содержит сложную логику, вынесите его в отдельный класс
• Тестируйте поведение — фокусируйтесь на том, что делает класс, а не как
• Избегайте reflection — это усложняет поддержку тестов
• Используйте моки — для изоляции тестируемого класса от зависимостей

// Было: private double applyTax(double amount)
// Стало: double applyTax(double amount) // package-private

// Теперь тест в том же пакете может вызывать метод
@Test
void applyTax_shouldAdd20Percent() {
    OrderProcessor processor = new OrderProcessor();
    double result = processor.applyTax(100.0); // доступно!
    assertEquals(120.0, result);
}