CODEWITHSUNDEEP
restbddwebrequestspecflowintercept
VinothNair
VinothNair

Reputation: 634

How to assert the request sent to restful web service from a BDD test (specflow with nunit)

I am writing a BDD style test for a new requirement from a client.

Just to give a background of the system under test. We have a windows service which is listening to a TCP port. This windows service is responsible for processing the messages send by clients on the port and respond to the clients.

The processing involves

1) finding the right message processer based on the request
2) then formatting the request that the third party service can understand
3) send the formatted request to the third party Restful web service
4) reformat the response got from the web service and send it to the client socket.

For the BDD purpose we have created a self hosted mock restful service which will send responses based on the configured messages for each request.

Till now all our tests are based on what we send to the port and what response we got in the port. With this approach we were able to cover all the functionalities in the BDD tests.

Now the new requirement is if the client sends a extra element in the message body then the third party service should also get the extra element. If the client is not sending the extra element in the message body then we should not even send the element to the third party service. We have done this change (updated the POCO request class with ShouldSerialize method) and also tested the result using log files.

But we are struggling to cover this from the BDD test. This is because our test acts as a client and posts the messages on the port, as we have control only on the response received from the port we are asserting only the response. We don’t have control on the third party service call because that happens inside the windows service production code.

Is there any way we can intercept the request send to the restful web service from the test to assert the request to check whether the request is formatted as expected.

Note: We are using C#, specflow with Nunit.

Upvotes: 1

Views: 1210

Answers (3)

Greg Burghardt
Greg Burghardt

Reputation: 18783

It seems like you've got a piece of middleware that needs to have its own tests:

{Your Application} --> {Middleware} --> {3rd Party Service}
                                                 |
{Your Application} <-- {Middleware} <------------+

You should be creating unit tests or functional tests for the middlware separate from the larger application in order to test this new functionality of the middlware.

In your full application, don't test the communication between the middleware and the 3rd party service. This is a black hole from which you will never emerge. You are left with three sets of tests:

  1. Validate that {Your Application} <--> {Middleware} is working
  2. Validate that {Middleware} <--> {Mock 3rd Party Service} is working
  3. Deploy your application and middleware to an environment where these services are wired up properly, and do some manual testing.

user2389992 commented:

I am not able to write the test for first point from BDD because I have control only to write request to the port and assert the response on the port.

The key part here is "I have control only to write request to the port and assert the response". Your BDD test should not go any deeper than this. The service is a black box. You don't need to know what it's doing in order to test your main application. You just need to know "If I send the service this, it returns me that."

You need a completely separate suite of tests ensuring the middleware/service is interacting with the 3rd party service properly.

Lastly, you need a third completely separate suite of manual tests in an application environment with your application, the middleware and the 3rd party service wired up to make sure the integration of these layers is working properly.

Upvotes: 1

James
James

Reputation: 1

Are you trying to describe your API with your BDD tests to get some type of documentation? Perhaps the following article could be helpful: http://java.dzone.com/articles/documenting-api-using

Upvotes: 0

Sam Holder
Sam Holder

Reputation: 32936

I think your only option is to be able to run your test with a stub 3rd party service which you can then interrogate to check was called correctly.

You might be able to create a test proxy service which logs the call somewhere for you tests to check and then calls the actual service. You might be able to get away with a simple decorater for your initial service.

Upvotes: 0

Related Questions