Why wm jbehave

Improving unit testing

Having tried different approaches to testing integrations, there appeared to be a feature and productivity gap in the way unit testing webMethods services was being performed.

Unit testing is important to isolate collaboration between services and target specific functionality such that you can significantly exercise the service under test with a high degree of confidence that you’ve covered all conditions and execution paths. In addition, having these test available to immediately run in Designer and frequently run during a build increases the ability to change services and refactor behaviour.

What was wanted were tests that were easily readable by developers or testers, tests that described what was happening and the reason for them. Having the ability to mock out and isolate interaction with other services was key to making unit testing feasible without having crippling dependencies.

Executing a service doesn’t necessarily prove behaviour so being able to interrogate the pipeline with conditional expressions was important. Likewise, proving that a mock or a particular point in a branch, etc. has been executed and how many times verifies you’re executing what you think you’re executing. And above all, the test framework had to be extensible to cope with evolving requirements and keep it productive and coherent in its approach.

Unit testing with JBehave

JBehave, JUnit and a custom framework gives an adaptable solution to unit testing. Fundamentally, JBehave uses a Behavioural Driven Development (BDD) style to describe tests. BDD is a natural language approach to writing tests and is formed of constructs to express the behaviour and expected outcomes. The approach with JBehave leverages its BDD language style with set phrases suitable for integration unit testing. Adding the plugin for Designer removes ‘blank editor’ issue when confronted with just plain, non-highlighted text. Its syntax highlight and content assist act as an aide memoire when constructing tests.

To fulfil the need for expressions, Apache Commons JEXL was chosen for its range of expressions, extensibility, maturity. It was easily enabled to make the pipeline accessible, with the implementation located in wm-aop-util.

Underpinning all of this is an AOP style framework (wm-aop) that allows interception of service before or after they are called, to alter or check the pipeline, or can it replace a service in it entirety to Mock service behaviour.

The AOP framework is flexible enough to inject any form of interception code and with its restful interface can be used with other test tools, such as Smartbear Ready!API

Dan North created JBehave and he describes its creation here