Expectation vs testing

Behaviour-driven-design advocate Manish and I have just had a chat over IM. He’s pointed out to me that checking things after the event is just testing, whereas anticipating things before the event is design. Design is good. Bugfixing is a pain.

On the back of that discussion, I’m thinking that JBehave’s Story Runner should probably run a scenario as follows:

Given a context
Then this outcome should occur
When an event happens.

Which ties in nicely with the “should” mechanisms / language of JBehave.

I may, given the JBehave team’s permission (or without it, even, ‘cos it fixes a bug I need fixing) refactor the scenario invoker to perform the above steps, and write a scenario verifier which checks that the anticipated outcome occurs.

I still can’t check that a given method got the arguments after the event. Maybe you should be able to “store” an expected method call on a mock by a key, or some kind of id, so that you can check it afterwards? In fact, I think JBehave’s Minimock already does this… hmm…

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s