I got the following question from a blog reader recently and the answer should be interesting to many other people:
With simple scenarios it’s all well, but we have a very complex domain. Do you have any examples of Cucumber files with very complex domains and features?
A former colleague had a great reply to situations such as this one: I disagree with the question! Unlike him, I’d like to also offer an explanation why I disagree.
There are no good templates for complex specifications with examples out there in the wild, ready for people to download and copy-paste. This is for a very good reason. The more complex a domain is, the more likely it is that developers and testers will misunderstand the intricate details and implement something that wasn’t requested or waste time on testing the wrong things. So in that sense, as the complexity of domain increases it is even more important to prevent misunderstanding. This is where simple scenarios are your friend and complex scenarios are the guy who sells you cigarettes loaded with firecrackers and runs away to watch them blow up in your face. It is with complex domains that the power of specification by example really comes through, but it comes through by making people spot complexity quickly and deal with it.
If a table has 50 rows and 50 columns, it is everything but easy to understand. If something is hard to explain, it will be hard to implement correctly and validate it. That means it will have a very slight chance of successfully passing through the delivery pipeline. You can see immediately that explaining things in that model makes no sense, and take action. Fast feedback is key to effective delivery. You know straight away that a spec is wrong, without having to go through two weeks of painful labor to see that the baby doesn’t want to come out.
You should then invest time in remodeling the examples. Try to explain and specify differently, break it down and look for higher level concepts to create useful abstractions. Do this until you get to a point that presents the target feature in a way that is self-explanatory to anyone with a bit of domain knowledge. “Clear”, “Easy” and “Meaningful” are among the top aspects of good cucumber files according to the workshop with almost 100 people at CukeUp in March this year. Rick Mugridge has some nice ideas in his KnowHow articles. Phil Trelford has some good ideas on restructuring bad tests on his blog. I have a whole chapter on refining examples in Specification by Example.
Simple models can describe very complex domains. But don’t take my word for it. Check with your local physicist how much complexity hides behind a simple formula such as e=mc<sup>2</sup>. Simple does not mean easy. It means someone bothered to explain it nicely. People saying that they don’t have time to do this are fooling themselves. Fire up google and search for “Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus court” while contemplating whether you have time to make your specifications simpler and easier to understand, or if you have enough slack in the process to waste time on reimplementing and retesting everything five times.
Very often the same people asking for more complex examples know very well the value of simple code design and architectures, but don’t see that the same applies to the specifications as well. KISS is one of the most important design rules today, but the community at large has to realise that the same applies to examples and models that they describe. Nice Airport has a great sign for quick drop-off: Kiss and Fly. I think we should adopt this as our mantra for specifications. Keep them simple and the software will fly!
