SRP and Unit Testability in Java

Direct Answer

SRP can improve testing by isolating one policy from unrelated infrastructure and reducing irrelevant setup. A pricing rule can be tested with a small input instead of booting web, database, and mail components. This is a common benefit, not a guarantee: focused classes can still need collaborators, and integration tests remain necessary for wiring and real boundaries.

Code Example

final class TaxPolicy {
    BigDecimal calculate(Order order) {
        return order.subtotal().multiply(new BigDecimal("0.18"));
    }
}

@Test
void calculatesTaxFromSubtotal() {
    var policy = new TaxPolicy();
    var order = new Order(new BigDecimal("100.00"));

    assertEquals(new BigDecimal("18.0000"), policy.calculate(order));
}

The rule can be tested without an HTTP request, database, or mail client. Separate integration tests can verify those boundaries where they actually exist.

Common Mistakes & Pitfalls

• Treating fewer mocks as the definition of SRP: test setup is evidence, not a rule.
• Replacing every collaborator with a mock: simple values or fakes may express a contract more clearly.
• Calling every Spring integration test a design failure: use integration tests for wiring and real boundaries.
• Splitting without a cohesive responsibility: smaller classes are useful only when their purpose is clearer.