expectations - 2 questions

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

expectations - 2 questions

Post 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?
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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?
Post Reply