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() {
setOn(true);
}
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() {
lamp.Attach(observer)
lamp.SwitchOn()
Assert.IsTrue(observer.SeesLight());
}
( 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.
Monday, October 31, 2005
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment