Test rig in TDD (test driven development)

Question

My company want to apply TDD in our projects and we began to study TDD 5 months ago. We start from writing unit to acceptace tests ( you can see in http://uet.vnu.edu.vn/~chauttm/TDD/). Then we follow this book "growing_object-oriented_software_guided_by_tests" to do a pilot project. But we have a problem with test rig( architecture to test end to end system) https://docs.google.com/file/d/0B23s8xkJtB5ZNHBJbEZ3YTdMTWc/edit. We have 3 teams, a team develops service side, a team develops Android client and a team develops iOS client. Following above test rig, client teams will write acceptance tests and insert directly data into database. The service team will create an sql file then client teams will use this file to insert into database. The client teams do not know about all database ( Our system has more than 200 tables) and sometimes, they have to spend a lot of time to debug because they do not know the service errors. Can you give me another test rig or suggest me the ways to make our projects ( in TDD) more effective ?

Answer 1

The client teams should have a mock service layer that they write automated tests against. These will have the advantage of running quickly and not requiring coordination with the service team. Most of the acceptance tests for the client application should be written this way. If you were writing an app that uses the Google calendar API, you wouldn't try to recreate the entire calendar API, you'd just mock out the calendar API the way you expect it to work.

For integration tests between the teams you can have a version of the production service on a separate server with a copy of the production database with some test data in it. For testing, configure the clients to use the test endpoint instead of production.