[rspec-users] Mocks? Really?

Zach Dennis zach.dennis at gmail.com
Tue Jan 1 17:40:35 EST 2008

On Jan 1, 2008 1:48 PM, Francis Hwang <sera at fhwang.net> wrote:

> On Dec 31, 2007, at 1:10 PM, Zach Dennis wrote:
> > I don't think it is "designing less" either. It's designing better
> > and doing it smarter, knowing that you'll never fully comprehend
> > the domain of your problem upfront, so you discover it,
> > iteratively. As you discover more about the domain the design of
> > your program changes (during refactoring) to support a domain model
> > to which it is representing.
> >
> > This is a concept from Domain Driven Design.
> >
> > It Francis is referring to doing less upfront design to try to
> > master it all from the outset, then I agree that less of that is
> > better. But that is entirely different then just doing less design.
> I'm not certain how much we're genuinely disagreeing here and how
> much we're talking past each other -- I'm certainly feeling like I'm
> not communicating my amorphous ideas very well.

I think I understand what you are trying to get across. That is why
I've communicated back what I think you have said (or at least what I
think you mean) in each of my responses, hopefully clarifying my
position (in both agreement and disagreement) to something more
specific, since phrases like "designing less" can be taken in several
ways and carry several different meanings. I'd much rather discuss a
particular aspect of "designing less" where it is advantageous or

> One thing that seems fuzzy to me is the implied time frames here. Let
> me ask you this, Zach: Is it your aim that your released code always
> contains a set of classes whose interactions with other classes is
> well-structured and defined, through mocks, and other tools?

It is my aim that objects, their responsibilities and their
interactions are purposefully structured and defined. For me, this is
through the iterative process of adding features to the system in a
TDD/BDD manner. Since I test drive feature implementation I have
explicitly made a decision to create a new object, add a
new responsibility to an existing object, or move responsibilities
from one object to another.

Mocks are simply a tool that I use to help me discover interfaces and
objects. They also help me express the coordination and interaction
between objects which fulfill an application requirement, and they
provide the added benefit of testing objects in isolation without the
unnecessary complexity of testing objects throughout the test
suite (which I believe strict state based testing of everything does).

I do not use any tool primarily for the sake of designing a
well-structured class taxonomy or detailed system design. No all
encompassing UML diagrams or oodles of documentation. I strive for the
domain driven design principle of having the domain model in the code
accurately reflect the domain you are solving a problem for.

> And is
> it your belief that you can always seek to release code which
> embodies a precise understanding of the domain in question?

I believe you can always seek to release code which is an accurate
reflection of the domain you are solving a problem for. I do not
believe that the code itself will be a precise understanding of the
domain in question. The features you implement will be solving a
specific problem in a given domain. What is required to implement
those features are only part of the domain. Ideally, what is
implemented is only "precise" enough to satisfy the feature
requirement. A lot of parts of the domain will be missing.

Initially, the understanding of the domain may be fuzzy at best. But
you start with a single feature to implement and you begin modeling
the domain within your codebase for only what is required to implement
that feature. You may only end up with a couple of objects; hardly a
"precise" or perfect understanding of the domain at large, but as more
features are added and time passes you get a better grasp of the
domain. As you implement more features you will most likely discover
new objects and responsibilities. This may entail extracting behavior
from existing objects onto a new object because it better reflects
what is required in the domain or it may promote single responsibility
or separation of concerns and the concept of simple objects.

The whole process though is something that is learned, continually and
incrementally. I don't stop development of a feature because I am not
an expert of the domain I am working in. I have to understand what is
required to implement a particular feature or solve a particular
problem anyways -- so I try to understand how the business expert or
customer understands it and I try to keep that understanding
consistent within the codebase. Specifically the domain objects in the

I agree with a lot of the concepts behind domain driven design and how
it works with agile (specifically XP in my case) development. It has
created simpler code, easier to understand and maintain code and
better test suites for apps that I've worked on.

> I suppose part of what I'm saying is that sometimes, for non-
> programmer reasons, the domain itself is too fuzzy or too quickly
> shifting to try to nail down with a well-structured design. Sometimes
> you just release code that amorphously hints at a future design --
> and in those cases, a strong test suite is what prevents you from
> shooting yourself in the foot.

I agree that the domains in which we are implementing features and
solving problems for are largely fuzzy. This is why it is so important
to have business experts and real users apart of the development
process. Sometimes it's not always possible to have direct access when
you need it or your customer is venturing into new territory and they
are trying to figure things out as they go as well. This is why
it's so important to have a clean code base which reflects the domain
because when that shifts we know what has to shift in our code.

For me well-structured is a relative term. It shifts with each feature
I add, remove or change in the system. After I complete a feature I
want the codebase to be a coherent reflection of the features it
includes. Over time the system is going to change and evolve, and parts
and pieces are going to be added or thrown away. My implementation may
not always be the best possible but it will be the best I could do at
a given time. And it will always strive for simplicity over complexity
and it will have a strong test suite.

This is probably a longer reply then you were looking for.. hopefully
thats alright. ;)

Zach Dennis

More information about the rspec-users mailing list