• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to develop and test the data services the BDD way?

 
Thillai Sakthi
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello John,

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 ?

Thanks
 
John Smart
Author
Ranch Hand
Posts: 43
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Thillai Sakthi
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
John Smart
Author
Ranch Hand
Posts: 43
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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):

def "should return correct customer details"() {
given:
def customerId = 100
def expectedCustomer = ...
and:
databaseContainsCustomer(expectedCustomer)
when:
def customerRecord = customerWebserviceClient.findById(customerId)
then:
customerRecord == expectedCustomer
}

(or something similar in JUnit, of course).
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

John,
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.

(For interested readers, go to http://docs.spockframework.org/en/latest/data_driven_testing.html and read the brie section on Data Tables.)

Thanks,
Burk
 
John Smart
Author
Ranch Hand
Posts: 43
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Data-driven testing in Spock is pure awesomeness :-).
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looks like another thing I'll have to play with more -- and remember to use @Unroll so I can see how each row of data fared.

Burk
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic