This is part 3 in my series about BDD and MicroServices. You may want to read part 1, and part 2 first.
As I have blogged about earlier, I have been spending some time exploring BDD/executable examples in a MicroServices environment, and how we can benefit from executable examples (SBE, Specification By Example) here at SpeedLedger. It has been a really good learning experience, and fun too.
Thanks to the initial progress, I have managed to persuade my boss to let me work on this full time! We are doing it as an time-limited experiment, but hopefully this will be extended.
In this blog post, I would like to share one of our greatest takeaway so far: That End-to-End Exploratory Testing is more valuable than End-to-End Regression Testing.
Both categories are valuable of course, but if I had to choose to have a really good setup for exploratory tests OR only a great suite of regression tests, I would definitely choose the former. Having automated fixtures (setup procedures) for interesting “moments” in the lives of our customers when using our product is super valuable, and I will list the reasons below.
When all this started, we named the experiment “BDD across team borders”. This was a good name at the time, but we later realised that the benefits of BDD/SBE can be appreciated by all co-workers, even those outside development teams. We have identified three main areas where we – as a company – can benefit from automated environments and automated test data:
If you are teaching yourself a new app/system/service, wouldn’t it be great if you could experiment and explore all aspects of it without being afraid to destroy anything? And in a simple way set up situations that the typical customers face every day?
Similarly, if you are training a new hire about your system; Wouldn’t the training be more efficient and fun if you could go through these scenarios interactively, setting them up with the touch of a button?
When discussing existing or new features with you peers, what would it be like if you could throw up a the system on a wide-screen monitor, demoing the current feature in question and the proposed solution respectively. While being able to repeat all setup step automatically and indefinitely?
Compare this to discussing features with the help of only stale sketches or obscure user stories.
This is the obvious one, of course. Most people think that verification of current features is the only benefit of automated test. But as we have seen above, there are several nice bonus effects.
In addition, there are other – maybe more subtle – positive side effects that come from using the test-first mindset. But that is a different story…
How about you? Can you automatically setup the preconditions for your customers’ most interesting interactions with your product?