Question

I’m writing test code to test a client-server application. The application under test consists of

1. an application that runs on Tomcat
   or another Java EE application server, and
2. client jars that expose an API.

I’m basically writing test code that uses this client API to connect to the server.

In addition to extensively testing the API operations, my superiors have advised me to connect to the database on the server and verify that fields are being populated properly. I have done that for some of my test cases, but it hasn’t really caught any bugs during regression.

Bugs are caught when a particular functionality fails, but that anyway gets revealed in the code that tests the API itself. It seems that DB data verification is not really useful, especially considering the extra effort required to write and maintain all that code.

My question is:

Is there any real benefit to write test code for connecting to the DB and verifying entries in this manner? Do the benefits pay off for the costs incurred in writing such code?

Answer 1

Reading the database is unnecessary for such tests. You can achieve better results by testing that:

1. Save requests return a success status.
2. Get requests return the saved data.
3. The saved data is returned by a get request even after you reset client state ie. take client-side caching into consideration.

If you test the database contents, your test cannot be used to see if a change in the database works, because the tests expect a certain state in the database. If this is changed, your tests fail, even if the system works.