Monday, October 31, 2005

Unit-Test and Mocking

1st. ObjectMentor: StopMockingMe (Mocks by Hand vs. Dynamic Mocks)
2nd. ThoughtWorks: Mocks are Evil

I think that the notion of OO is not really well understood: in an OO-world, we have objects,
and messages. Object A sends the message MSG to object B.

“...things often go wrong where one part of a system communicates with another (e.g. business logic connects to a database). The mocked out functions are usually called correctly, but something else is going wrong (e.g. permissions have not been set on the database).” (from comments)

I have the impression that it is not cleared what is it tested, what Unit are we testing now?
Are we testing the object A who sends a message to B, or are we testing B, which is a DB access point? In an OO world, A has no ideea hat implementation has B, and if a DB is behind. Probably,
the right question is: we have not defined how A will react, if B does not respond to the message,
or if it throws an exception.

“Why we should use mocks when we could test for free all underlying layers?” (other developers conversations).
Unit-Test !? We are testing an object, who works with several interfaces... (see PicoContainer-GoodCitizen).

And now from the original post, the story about the Lamp and the Light:

Lets take classic object Lamp.

public class Lamp {
private boolean on;
public void switchOn() {
public boolean isOn() {
return on;
private void setOn(boolean on) {
this.on = on;

Might be I am missing something here. How can we make sure switchingOn behavior worked correctly without verifying the state (on/off) of Lamp?

Isn't this a philosophical question?
Is it there really a light if you are not there to see it? (I think there is an old chinese saying with a falling tree in a forrest)
Do we have light if the Lamp's button says that the lamp is on?

Maybe a better approach would be:

testLampObserverSeesLight() {

( I still think that test_observer_sees_light_when_lamp_switch_on() is a better name :D)

Bottom-End: Unit-Tests are a base for your development. If they are incomplete: is your fault.
If you test Setters/Getters is your fault. If you want to test the DB in the BussinessLogic layer: is your fault.

No comments: