I am referring to the article Mocks aren’t Stubs by Martin Fowler. When naming cases when he think “mockist” TDD will be advantageous, he said
It’s particularly worth trying if you are having problems in some of
the areas that mockist TDD is intended to improve. I see two main
areas here. […] The second area is if your objects don’t contain
enough behavior, mockist testing may encourage the development team to
create more behavior rich objects.
My question, what does he mean by “behavior rich objects”, objects that “contain enough behaviour”, etc? And why does it matter if an object contains many behaviour or not, if it works correctly?
I think the quote is referring to objects which are (mostly) devoid of logic, representing only data. This is referred to as the Anemic Domain Model, and is generally an anti-pattern in OOP. From the Wikipedia article:
Anemic domain model is a term used to describe the use of a software domain model where the business logic is implemented outside the domain objects.
So basically, your quote seems to be saying that TDD (and specifically, mocking) encourages people to move their logic into the object (where it should have been, in the first place). I’ve noticed this myself, but don’t have any actual data to back it up.
Edit:
To clarify, I’m simplifying here by pointing out one end of the spectrum, the anemic domain model. Fowler is probably referring to more of a soft-defined “sweet-spot”, where your object contains an “optimal” amount of logic (by some measure). This object would be complicated enough to warrant its existence, but not so complicated so that it should yet be split into multiple. Of course, this is very difficult to define, so I’ve stuck with the simple explanation.