Page 1 of 1

expectations - 2 questions

Posted: Wed Dec 26, 2007 9:59 pm
by alex.barylski
1) Is there a way to add to the message displayed by SimpleTest when it detects a mismatch of expectations against actual invocations?

For instance, currently I receive an error like:

Code: Select all

testShouldReturnValidPkid -> Expected call count for [loadSomething] was [1] got [2]
I would like to add some additional verbiage so when that error is raised...the message will offer more details as to why the error occurred. Something like:

The required invocation of loadSomething absolutely must not exeed 3 calls in the context of so and so function, otherwise this or that system will be effected. This is due to the fact that sometimes, somethings go wrong, etc, etc...

You get the point I'm sure...basically just want to add more to a generic error message when expectations are not met.

2) Next question has to do with setting expectations and best practices...seems a powerful idea...holding an implementation to something of a contract, but I can see this getting tedious, messy and maybe difficult to maintain as implementation is much more dynamic than it's interface...

Using expectations frequently in your experience, has it led to a more structured, organzied approach to developing software, or does it cause more headaches than it's worth?

Posted: Fri Jan 04, 2008 11:08 am
by Jenk
Definitely worth it, and quite frankly required to make a test/spec for any object that requires a mock object.

I prefer concise messages, and as such the existing "Expectation [expectationName] was called [ 1 ] times expected [ 2 ]" is fine for me. My spec will tell me what else I need to know for expected behaviour, and comments (within the spec) will fill me in on the rest.

If regressing to UnitTesting, any information other than the object behaviour and interface is superflous. The behaviour you are testing will not know the context, so why should the test?