编写可测试代码-JUnit测试：单元测试转集成测试难题求助

Hey there! Let's break down each of your testing scenarios, fix those headaches, and talk about how to make your code more testable from the start.

1. Service Layer Tests Turning into Integration Tests (Mocking JPA Tuple) #

The problem here is thinking you can't mock javax.persistence.Tuple—but since it's an interface, you absolutely can! No need to hit the database at all.

Solution: Mock the Tuple Interface Directly #

Use Mockito to create a mock Tuple instance, then stub its get() methods to return the values your service expects. Here's an example:

@ExtendWith(MockitoExtension.class)
public class OrderServiceTest {
    @Mock
    private OrderRepository orderRepo;
    @InjectMocks
    private OrderService orderService;

    @Test
    public void testSummarizeOrders() {
        // Create a mock Tuple
        Tuple mockOrderTuple = Mockito.mock(Tuple.class);
        when(mockOrderTuple.get("orderId", Long.class)).thenReturn(100L);
        when(mockOrderTuple.get("totalAmount", BigDecimal.class)).thenReturn(new BigDecimal("99.99"));

        // Mock the repo to return your mocked Tuple list
        when(orderRepo.fetchOrderSummary()).thenReturn(List.of(mockOrderTuple));

        // Execute the service method and assert results
        List<OrderSummaryDto> summary = orderService.generateOrderSummary();
        assertEquals(1, summary.size());
        assertEquals(new BigDecimal("99.99"), summary.get(0).getTotalAmount());
    }
}

This keeps your test strictly unit-focused—no database calls required.

2. Testing Methods with Static Factory Classes #

Static methods are notoriously hard to mock, but you don't have to fight them. The fix involves refactoring to decouple your code from the static dependency.

Solution: Wrap Static Calls in an Injectable Factory Interface #

Replace direct static factory calls with a dedicated factory interface that you can inject and mock. Here's how:

Step 1: Refactor the Code

// 1. Define a factory interface for your instance creation
public interface PaymentProcessorFactory {
    PaymentProcessor createProcessor(String paymentType);
}

// 2. Implement the factory to use your original static logic (or Spring bean creation)
public class DefaultPaymentProcessorFactory implements PaymentProcessorFactory {
    @Autowired
    private AutowireCapableBeanFactory beanFactory;

    @Override
    public PaymentProcessor createProcessor(String paymentType) {
        // Replace with your original static factory logic, using the beanFactory if needed
        if ("credit".equals(paymentType)) {
            CreditCardProcessor processor = beanFactory.createBean(CreditCardProcessor.class);
            processor.setApiKey("test-key");
            return processor;
        }
        // ... other cases
        throw new IllegalArgumentException("Invalid payment type");
    }
}

// 3. Inject the factory into your service instead of calling static methods
public class PaymentService {
    private final PaymentProcessorFactory processorFactory;

    // Constructor injection (best practice for testability)
    public PaymentService(PaymentProcessorFactory processorFactory) {
        this.processorFactory = processorFactory;
    }

    public void processPayment(String paymentType, BigDecimal amount) {
        PaymentProcessor processor = processorFactory.createProcessor(paymentType);
        processor.charge(amount);
    }
}

Step 2: Write the Unit Test

Now you can mock both the factory and the processor it returns:

@ExtendWith(MockitoExtension.class)
public class PaymentServiceTest {
    @Mock
    private PaymentProcessorFactory processorFactory;
    @Mock
    private PaymentProcessor mockProcessor;
    @InjectMocks
    private PaymentService paymentService;

    @Test
    public void testCreditCardPayment() {
        // Mock the factory to return your mock processor
        when(processorFactory.createProcessor("credit")).thenReturn(mockProcessor);

        // Execute the service method
        paymentService.processPayment("credit", new BigDecimal("50.00"));

        // Verify the processor was called correctly
        verify(mockProcessor).charge(new BigDecimal("50.00"));
    }
}

If you can't refactor right away, you could use PowerMock to mock static methods—but this is a last resort, as it complicates tests and can hide design issues.

3. Testing Methods That Use new Instead of @Autowired #

When you create instances with new ConcreteClass() inside a method, you're hardcoding a dependency that Mockito can't replace. The fix is to externalize that dependency.

Solution 1: Inject the Dependency via Constructor #

If ConcreteClass is a stateless service or reusable component, inject it directly:

// Refactored service
public class InvoiceService {
    private final PdfGenerator pdfGenerator;

    public InvoiceService(PdfGenerator pdfGenerator) {
        this.pdfGenerator = pdfGenerator;
    }

    public File generateInvoice(Invoice invoice) {
        // No more new! Use the injected instance
        return pdfGenerator.createPdf(invoice);
    }
}

// Test
@ExtendWith(MockitoExtension.class)
public class InvoiceServiceTest {
    @Mock
    private PdfGenerator pdfGenerator;
    @InjectMocks
    private InvoiceService invoiceService;

    @Test
    public void testGenerateInvoice() {
        File mockPdf = new File("mock-invoice.pdf");
        when(pdfGenerator.createPdf(any(Invoice.class))).thenReturn(mockPdf);

        File result = invoiceService.generateInvoice(new Invoice());
        assertEquals(mockPdf, result);
    }
}

Solution 2: Use a Factory for Dynamic Instance Creation #

If you need to create a new instance of ConcreteClass every time (e.g., it's stateful), wrap the creation logic in a factory interface (similar to scenario 2). This lets you mock the factory to return a mock instance when needed.

General Tips for Improving Code Testability #

To avoid these issues in the future, follow these practices:

• Prioritize constructor injection: It makes dependencies explicit and easy to replace in tests (no need for @InjectMocks if you pass mocks directly to the constructor).
• Depend on abstractions, not concretions: Program to interfaces instead of specific classes—this makes mocking trivial.
• Avoid static dependencies: Static classes/methods create tight coupling; wrap them in injectable interfaces when possible.
• Never hardcode new for dependencies: Any object your class needs to do its job should be injected or created via a factory you control.

内容的提问来源于stack exchange，提问作者JustStarted