Testing a Hexagonal App

Here's where all the ceremony pays off. Because the domain and use cases depend only on ports - not on Spring, JPA, or HTTP - you can test them in plain memory, with fake adapters, at unit-test speed. No database to spin up, no @SpringBootTest context to load, no mocking framework gymnastics. This testability is the single most compelling reason to adopt the architecture, and it aligns beautifully with the testing pyramid.

Testing the core with fakes

A use case depends on ports. To test it, supply fake implementations of those ports - usually simple in-memory ones - and exercise the real business logic:

class TransferMoneyUseCaseTest {

    @Test
    void transfers_money_between_accounts() {
        // in-memory fake adapters - no DB, no Spring, no mocks
        var accounts = new InMemoryAccountRepository();
        accounts.save(new Account(AccountId.of("A"), Money.usd(100)));
        accounts.save(new Account(AccountId.of("B"), Money.usd(0)));
        var events = new RecordingPublisher();

        var useCase = new TransferMoneyUseCase(accounts, events);   // wire the real use case

        var result = useCase.transfer(AccountId.of("A"), AccountId.of("B"), Money.usd(30));

        assertThat(result.isSuccess()).isTrue();
        assertThat(accounts.findById(AccountId.of("A")).get().balance()).isEqualTo(Money.usd(70));
        assertThat(accounts.findById(AccountId.of("B")).get().balance()).isEqualTo(Money.usd(30));
        assertThat(events.published()).contains(new MoneyTransferred("A", "B", Money.usd(30)));
    }
}

This test runs in milliseconds, tests real business logic (the use case and the Account entity's invariants), and reads like a specification of the behavior. There's no database because the use case never knew about one.

Fakes over mocks

Notice these are fakes (working in-memory implementations), not mocks (objects programmed to expect specific calls). Fakes are usually the better choice for ports:

• An InMemoryAccountRepository backed by a HashMap behaves like a repository - save then findById actually round-trips - so tests exercise realistic behavior, not a script of expected calls.
• Mocks couple the test to how the use case calls the port (verify(repo).save(...)), so they break on harmless refactors. Fakes couple only to outcomes.
• One well-written fake is reused across dozens of tests; mock setups are re-specified each time.

Write a fake adapter for each driven port once, and your entire core becomes trivially testable.

Aligning with the testing pyramid

Recall the classic pyramid: many fast unit tests, fewer integration tests, a handful of end-to-end tests. Hexagonal architecture maps onto it cleanly:

• Unit tests (the wide base) - domain entities and use cases with fake adapters. Fast, numerous, where most of your business-logic coverage lives.
• Integration tests (the middle) - each real adapter against its real technology: JpaAccountRepository against a Testcontainers Postgres, the REST adapter against a running context. You test that the adapter correctly translates, not the business rules (already covered by unit tests).
• End-to-end (the tip) - a few full-stack flows through the real driving adapter, real DB, everything wired.

The architecture tells you what to test where: business rules at the unit level with fakes, translation correctness at the integration level per adapter, and only a thin layer of full E2E. You stop writing slow, brittle @SpringBootTests for logic that a millisecond unit test covers.