Develop a test framework for validating responses of Soap WS with REST WS?

Question

I have a requirement to develop a test framework using Cucumber .

Requirements:

1. There is a Soap WS already developed for an existing project few years ago
2. There is a new REST ws developed for the same project

I have to validate the responses from the SOAP WS with responses of REST WS and check if both are same or not using a feature file (cucumber)?

basically have to check if fields values in Soap and REST are equal.

how to write the scenario and how to map those fields in SOAP ws with REST ws?

I am very new to BDD and cucumber. elaborate answers are very much appreciated

Answer 1

How to create the scenario

In BDD, we create a scenario with contexts, events and outcomes.

The context is the state in which the scenario starts. So in your case, you have two services, and probably something created in those services that might change the responses. Those become your "Given"s.

Let's say your services are dealing with user details. (Adapt these accordingly for whatever information matters to your scenario.)

Given the REST service has a user 'Chandra Prakash'
And the SOAP service has a user 'Chandra Prakash'

Most of the time in BDD we only have one event happening in each scenario. There can be two events though if there's interaction or something like time passing, and I think this counts too. So we make a call to both services, and the events become your 'When'.

When we ask the REST service for all users with family name 'Prakash'
And we ask the SOAP service for all users with family name 'Prakash'

And the last bit is the outcome, where we look to see if we got the value that's important to us.

Then both services should have found a user 'Chandra Prakash'.

Those lines, together, become the scenario in your feature file.

Rather than just having one scenario to verify that both are the same, I'd look for examples of what the systems do, and use one scenario for each example. But if you want that last call to just check they're both identical, that would be OK.

Wiring up the scenario to automation

Most examples of Cucumber that you find will use something like Selenium to automate over a web page, but you don't have that. Instead of a UI, you have an API. You're coming up with examples of how one system uses another system.

Your automation will be setting up data in the Givens, then calling the REST service or the SOAP service as appropriate in the Whens.

If you work through Cucumber's tutorial, and then use their techniques to wire the scenario up to the two services, you'll get what you're after.

Note that Cucumber has different flavours for different languages, so pick the right flavour for yourself.

Scenarios vs. Acceptance Criteria

In general, I like to ask, "Can you give me an example?" So, can you give me an example of what the REST service and the SOAP service do? If the answer is something of interest to the business and non-technical people, then you can write that example down. Try to use specific details, as I've done here with a user and their name, rather than being generic like

Given the REST service has a user with a particular family name
When we ask the REST service for users with that family name
Then it should retrieve them

This, here, isn't a scenario, even if it's good acceptance criteria. We want our scenarios to be specific and memorable. Try to use realistic data that the business would recognize.

Cucumber vs. plain code

There's one small problem that I can see.

It sounds as if what you're doing might be a technical integration test, rather than an example of the systems' behaviour. If that's the case, and there's no non-technical stakeholder who's interested in the scenario, then Cucumber may be overkill. It's enough to create something in the unit-level framework for your language (so JUnit for Java, etc.). I normally create a little DSL, like this:

    GivenThePetshop.IsRunning();
    WhenTheAccessories.AreSelected("Rubber bone", "Dog Collar (Large)");
    ThenTheBasket.ShouldContain("Rubber bone", 1.50);
    ThenTheBasket.ShouldContain("Dog Collar (Large)", 10.00)
    ThenTheBasket.ShouldHaveTotal(11.50);

But even that's not needed if you're not reusing the steps anywhere else; you can just put the "Given, When, Then" in comments and call straight to the code.

Here are some arguments I'd use against Cucumber in this instance:

• It's harder to refactor plain English than code
• It introduces another layer of abstraction, making the code harder to understand
• It's another framework for developers to learn
• And it takes time to set it up in CI systems etc. too.

If you can't push back, though, using Cucumber won't be the end of the world.

Have some conversations!

The best way to get examples out is to ask someone, "Can you give me an example?" So I'd find the person who knows the business processes best, and ask them.

Please do this even if it's just an integration test, as they'll be able to help you think of other examples in which the systems behave differently. Each of those becomes another scenario.

And there you go! If you do need help that StackOverflow can't provide, there are mailing lists for both BDD and Cucumber, and plenty of examples out there too.