Middleware Integration with BDD

Application integration is the joining of two pieces of software. This means their two Application Programming Interfaces (APIs) become integrated, allowing automatic transfer of data sets and instructions between the two.

What is Middleware Integration?

 Middleware is a product that sits between multiple primary business systems. For an example : CRM systems and accounting systems integrated with a middleware to communicate and share data. In other words Middleware translate the information from one system in a way the other system can understand just like a translator enables a french speaking person to speak to a Russian speaking person.Just like the above example, It is not necessary for the systems to have the same language. You could use pre-developed middleware for your Application integration projects.

Let's look at what is BDD

If you have no idea what is BDD, BDD stands for Behavior Driven development. This methodology is based on business people, testers and developers all sitting together to collaborate on the getting the requirements right so each feature is correctly understood by all members of the team before development process starts. This helps to identify key scenarios for each story and also to eradicate ambiguities from requirements. They will then write down the scenarios for each feature in the application in a plain English language so everyone can read and understand and contribute. For more information about BDD, check my post on Using Cucumber for Behavior-Driven Testing.

Why BDD for Middleware integration?

The applications integrated with middleware can be  large, complex, enterprise-scale solutions. For example, there can be many departments of an enterprise coming together.
In such case the developers or testers will not have a clear idea about the bigger picture. 
In these cases, the ambiguity is off the roof and understanding the requirements clearly before starting the development is crucial.
Unlike in ordinary application development, we run in to various tools, databases, technologies and even within a pre-developed middleware there might be different technologies and languages used. So keeping in track with the requirement for developers is a challenge. 
Do you want to try and remember all the crazy scenarios whenever you make a change, or do you want that safety net to let you know when you've broken the specification.

Starting  Middleware integration with BDD

An enterprise-scale solution might have a dozen of integrations. Taking them all at once and starting development will not be feasible or manageable. So we have our specialized integrations analysts to analyze and plan the integration project. 
Decomposing a large solution into a number of more manageable chunks is an age-old approach that scales up and works. The approach we should take is to decompose a solution into a number of significant integration components these component are integrated with middleware, and then work on the Behavior Specifications of each component, one-by-one. Each component should be considered individually, and the behaviors of each component should remain separated from those of other components. 

So you have your business analysts / Integration analysts with the business requirement, you have your developers ready to start coding, you have your testers urging to find bugs. BDD is all about collaboration among these three groups prior to the development starts. Now you start talking. Analysts will communicate the business requirement, developers will identify the features needed, testers will understand what to be tested. Everyone can discuss the business, raise questions and get them resolved. This will lead to minimum ambiguity among the group.

Now we need a way to record requirement in a meaningful but simple way. This is the point where Gherkin comes in to action. Gherkin is a plain-text language with a little extra structure. Gherkin is designed to be easy to learn by non-programmers, yet structured enough to allow clear description of examples to illustrate business requirement in most domains. Now we have got everyone collaborating and things are in action. Using gherkin we focus on one feature in the integration and start writing scenarios for that feature. When writing scenarios it is best to use domain terms and real domain examples.

Note : It is very important that the integration analysts get involved in defining the behavior of the integration and review the written scenarios. 

In above example we have one component taken in to account. Here we have encrypted files in a location (storage) as our inputs, these files might be coming from another integration in our solution. The middleware must copy these files in to another location and decrypt them. Then the data inside the files will be manipulated by the middleware as business needs and inserted them in to the database.

 Let's try to write some Gherkin steps for the above feature.

Feature : Middleware populates the database
Scenario : When storage has files, DB gets populated.
Given these "Abc" files are in the storage
When we execute the "middleware"
Then the DB will have the rows populated with "these" data
And the "Abc" location is cleaned.
And the "XYZ" location is cleaned.

If you follow the BDD right you will have some meaningful scenarios for features that describe how exactly the system should behave. 
Now the developers can start developing the middleware to meet the documented behaviour. 
Exercising BDD with a tool like Cucumber which is specially designed Behavior driven development comes with a bonus. Without even knowing this will provide you some regression tests as a nice by-product. 
But you should remember that the main goal is to do the analysis right with BDD, automating the cucumber scenarios is an option.
 If you automate the tests, when developers are done with coding, they can run the tests and see if the developed middleware behaves as required, if not keep rewriting the code till it passes the tests.