MockObjectsCodingStyle

The initial options we came up were: 1 don't try to be too pure. Put the flag in the ExpectationObject and set it. 1 if there aren't many cases, move the flag to the MockObject, and keep the ExpectationObject's clean. 1 "You don't need it - this is a CodeSmell?" JohnNolan suggested that this might be because one of your objects need splitting

In the end, inspired by a suggestion from CharlesWeir and some of the correspondence on Egroups, we came up with a working compromise:

• make ExpectationObject's in MockObjects public. Don't bother with getters and setters, get the names right and talk to the instance variables directly. This will be easier in the next edition of the BigBenTools because we've unified some of the API.
• ExpectationObject's include a flag to turn off their verification.

The unit test code should now look something like:

public void testMethod() { MockThingy? thingy = new MockThingy?(); thingy.myFoo.setExpected(new First()); thingy.myBar.setExpected(new Second()); thingy.myBlob.doNotVerify(); myTarget.doTheThing(thingy); thingy.verify(); // only verifies thingy.myFoo and thingy.myBar, not thingy.myBlob }

³host³³date³October 17, 2000³MockObjectsCodingStyl ³³agent³Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)³MockObjectsCodingStyle