Saturday, 15 June 2013

rest - 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 the client.

Just to give the background of the system under the test. We have a Windows service that is listening to a TCP port. This window is responsible for processing messages sent by customers to customers on the service port and responding to customers.

Processing includes

1) Finding the correct message processor based on request - 2) Then the form of request can understand third party service 3) Send third party formats Request Refill Web Service
4) Reform, response from web service received and sent to customer socket.

For the purpose of BDD we have made a self hosted silent silent service that will send responses based on the configured messages for each request.

So far, all our tests are based on the basis of which we have been sent to the port and the response received in the port. From this point of view we were able to cover all the activities in BDD tests.

Now the new requirement is that if the customer sends an additional element in the message body, the third party service should get additional elements. If the customer is not sending additional elements in the message body, then we should not send the element to the third party service either. We have made this change (updated POCO request class with corrected alias method) and also tested the results using the log file.

But we are struggling to cover it from the BDD test. This is because our exam serves as a customer and posts a message on the port, because we only have control over the response from the port, we are just pushing the reaction. We do not have control over third-party service calls because it is inside the Windows service production code.

Is there any way that we can stop sending this reliable web service to stop this request

Note: We are using C #, Speakflow with NZAT Whether or not it is a request to check it.

It seems that you've got a piece of middleware that should be self-examined:

  {your application} - & gt; {Middleware} - & gt; {Third party service} | {Your application} & lt; - {Middleware} & lt; ------------ +  

For middleware you should make unit tests or functional tests, from large applications to test this new functionality of the middleware.

In your completed application, do not test communication between middleware and third party service. This is a black hole from which you will never be able to emerge. You are left with three set trials:

  1. Verify that {your application} & lt; - & gt; {Middleware} is working
  2. Validate that {Middleware} & lt; - & gt; {Mock third party service} is working
  3. Apply your application and middleware to an environment where these services are well wired, and do some manual testing.

user2389992 Note:

I am not able to write the test for the first point of BDD because I only write the request for the port and the response to the port But to emphasize.

Here is the part of the key "Only I have the control to write a request on the port and emphasize the reaction". Your BDD test should not be deeper than this. Service is a black box to test your main application, you do not need to know what it is doing. All you need to know is "If I send this service, then it gives me."

You need a completely different suit to ensure bee / service, which is communicating properly with the 3rd party service.

Finally, you need a separate suite of manual exams manually, in which your application, middleware and third party service is wired in an application environment to ensure that That the integration of these layers is working properly.


No comments:

Post a Comment