A few years ago, I read Eric Evans’ seminal book “Domain-Driven Design” and (more recently) Vaughn Vernon’s equally excellent follow-on “Implementing Domain-Driven Design”. Both of them have had a transformative effect in how I build and design software. In many startups, you’re called on to wear many hats. In addition to traditional development manager and architect roles, I’ve often found myself filling in for product owner and quality assurance roles. Coming from a Lean/Agile background, the way that one typically captures requirements (and to a lesser extent, test cases) is through a User Story’s acceptance criteria. Acceptance criteria are generally expressed as a checklist – they’re how you know when you’re done your job. I’d always felt that – even with my system’s architecture, classes, and methods modeling my domain’s ubiquitous language – there was still a disconnect between our stories, our test cases, our design, and our code.
Enter Behavior Driven Development. Behavior-driven development (BDD) is a software development process based on test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software developers and business analysts with shared tools and a shared process to collaborate on software development. In short, BDD is the answer I’d been looking for – it’s how you incorporate Domain-Driven Design into your Requirements and Testing processes. At its core, BDD is a way to articulate business requirements in your company’s domain language. By following a set of simple language conventions called Gherkin, BDD allows developers, business analysts, and testers to get on the same page by literally all speaking the same language. One of the more useful qualities of BDD scenarios is that, when combined with a tool like Cucumber or SpecFlow, your requirements’ acceptance criteria becomes executable test automation code. This is clearly a powerful tool.
Since Merchant Warehouse’s product is (at its core) principally a set of SOAP Web Services, we had been using Smartbear’s SoapUI product as an integral part of our testing automation initiative. Unfortunately, we couldn’t find a great way to integrate SoapUI and our BDD Scenarios. The best advice we saw was to name your SoapUI test steps following Gherkin’s traditional “Given/When/Then” steps. Using that approach, your test steps at least resemble your BDD scenarios. But doing things this way would have meant a lot of copying and pasting between our SoapUI tests and our BDD Scenarios and a chance for these two files to get out of sync. Fortunately, we can do better.
After a little bit of digging, we came across Apache CXF’s wsdl2java command-line tool and we have been loving it ever since. Given a WSDL file, wsdl2java will generate fully annotated Java code from which to implement a service. It will create all of your POJOs and the code necessary to communicate over HTTP/HTTPs. It handles all of the XML marshalling and unmarshalling for you. Minus a bare minimum of boilerplate setup code, wsdl2java makes calling SOAP Services just as easy as calling a native Java method.
By combining wsdl2java, Cucumber, and Junit, our SETs and developers are able to quickly implement BDD style web services tests, in Java, without needing SoapUI or its pesky license fees. Combined with Jenkins’ Cucumber Reports Plugin, we have ourselves a powerful and robust testing framework.
Below is an example Gherkin file with our BDD scenarios, as well as the Java code that implements them. You can see that we’ve implemented a pure-java approach that encompasses both BDD and Data-driven testing (DDT). Using DDT, we’re able to quickly capture a number of positive and negative test cases in a language that’s very human-readable, and editable by a business analyst without any QA automation expertise.