Our C# application architecture involves a web service, a database and a Winforms application. The winforms application will call a method in the web service called ProcessFile.
I want to use Acceptance Test Driven Development techniques and have written the following Specflow user story.
Story: Process file
As a knowledge worker
I want to process a file
so that it can go onto the next step.
Given query A is True
And File A exists
When I run Process with File A
Then A backup of the existing file exists
And a new processed file exists
And query B is true
And query C is true
Our windows application will call the whole Process File story from the web service.
However in order to do BDD we were tempted to have a lot of little calls like IsQueryBTrue
This results in an undesirably chatty web service and we don't want IsQueryBTrue in the published API
I am now thinking that a lesser evil would be for the test project to call the data service directly and just have some smaller FileExists calls to the web service. However this doesn't feel quite right as surely the same code should be running in the test as in production.
How can I test adequately whilst avoiding making a chatty web service?
I am now wondering whether we should have used a web api or wcf rather than a wsdl web service
is there anyway from the API you want to publish to verify the behaviour you expect from your call to ProcessFile?
If there is then great, you should do this from your specflow scenario in order to validate that the behaviour is as you expect. This may be by executing some query or may be by visiting some other website or whatever.
If there isn't then you will need to validate the 'internal' expected behaviour. You can either do this via extensions to your existing web service to allow methods like IsQueryBTrue (or maybe a generic ExecuteQuery).
As you say you don't want to do this a better solution might be to provide another test service for the specflow tests to use to validate the internal behaviour. This service might only be deplyed for your dev testsing and not made available to the production system or might use an internal url or different credentials to authenticate to protect it being used by people using the production api.
At the end of the day if you are using Behaviour Driven Development there has to be some way to assert that the behaviour of the system is as expected and if there is no way to do this publically and the only way is internal checks that the tests have to be given the access to the internal systems to check.
For me it seems perfectly ok for the test to call the data service directly to check if the things that are needed exist, especially if those calls already exist in that service. This also seems preferable to adding new methods for testing only to the webservice.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments