I just started to implement the steps for something like the following story:
It started to get complicate as I was in need of a parameter converter (JBehave) which converts “Article” into an object representing the document type. After some time I realized that the story was again written by someone who knows the product in too much detail.
I stopped work on the converter and rewrote the story – and now the story tells what the customer really wants:
where “rendered property” (we are editing web-contents here) is another learning to specify cleanly what you want – here: If you want to show the text in the preview later on you first should ensure to choose a property which will become a visible part of the web page.
And suddenly there was no need for a parameter converter anylonger.
I don’t vote against parameter converters – I just have to repeat to myself again and again: Write what you (as customer) really want! – and don’t try to incorporate the knowledge about the test environment (here: document type of type Article exists) into the story.
Doing so will keep your tests more robust over time (perhaps one day there is no “Article” anylonger) and sometimes (as it was here) it will even ease your test code.
For how to handle the references in the stories above you might want to read my blog post “BDD Design Patterns: Reference Tracker”.
No comments:
Post a Comment