I am really heartened to see a chapter on testing web services in your upcoming book. While I get the application of TDD and now the BDD in applications/services/modules that have some kind of logic to be tested in them, how do we apply BDD principles in testing simple data services implemented as web services that simply fetch data from system of record given some inputs ?
Testing web services using BDD is much easier than testing via a web interface. BDD is about describing behavior, and writing executable specifications using a set of representative examples. BDD puts a lot of emphasis on the expected outcomes (or outputs) for different scenarios. So to apply BDD to a data service, you need to describe the expected data outputs for given inputs in your scenarios, and then implement web service calls to verify these expectations.
Joined: Jun 17, 2000
Thanks. But according to Dan North's blog http://dannorth.net/introducing-bdd/ and also your answers from other posts on this forum, the test cases are named more intuitively like "testShouldDoSomething" et al. So, for a typical data service, writing a test case such as "testShouldReturnListOfCustomersForAValidCustomerId" makes sense, however, how do you check for a specific field's value in the response ?
Is it like - testShouldReturnZipAs95315 and testShouldReturnCustomerNameAsJoeSmith and so on?
Joined: Aug 06, 2013
You probably wouldn't do an individual test for each field: rather, you would typically check the customer object as a whole. For example, you might write something like this (in Spock):
John Smart wrote:You probably wouldn't do an individual test for each field: rather, you would typically check the customer object as a whole.
What's your opinion on data driven testing in Spock? I like the idea of writing one method and providing multiple sets of inputs and expected outputs and if you use the @unroll annotation, you can see which sets of data passed and failed.