mocks and adapters

In A thought on mocking filesystems Brian Marick provides yet another reason to think in terms of a hexagonal architecture. Discussing the writing of mock objects for huge components such as a filesystem, he writes:

“So it seems to me that a project ought to write to the interface they wish they had (typically narrower than the real interface). They can use mocks that ape their interface, not the giant one. There will be adapters between their just-right interface and the giant interface. Those can be tested separately from the code that uses the interface.”

Mocks/stubs and adapters are natural bedfellows, and definitely help to keep code clean and testable. I once worked on a project in which the “filesystem” was a JNDI directory service. And then later that was scrapped in favour of a plain old filesystem. How I wish I had known about hexagonal architectures then, because it was a real nightmare to disentangle the JNDI dependencies from the rest of the system.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s