Monday, August 11, 2008

Mock Objects Not States

The dynamic duo back again... http://www.infoq.com/presentations/Mock-Objects-Nat-Pryce-Steve-Freeman.

A little taste:

Smell #1: the test exposes the internal implementation details of the object tested. It's clear that object encapsulation is broken.

Smell #2: passing too much information to the object tested with constructors having too many parameters. The object tested has too many dependencies, and it may be time to break it up in several smaller objects.

Smell #3: mock everything. One wants to mock dependencies and peers, but not value objects.

Smell #4: the tests just replicate production code. Code should not be replicated.

Smell #5: one needs to mock an object he cannot replace. External objects can be used, but cannot be mocked.

Smell #6: one needs to mock a concrete class. The tests are meant to verify relationships between objects, not to test a specific instance of an object.

1 comment:

Lyudmil Angelov said...

Thanks for the post - I have to go refactor most of the code I've written now. You may have recently come across this article that touches on a number of the same design principles:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html

It seems a little over-prescriptive, but I found it revealing in the same ways as the presentation.