Question

I want to allow consumers of a web services layer (web services are written in Java) to create automated integration tests to validate that the version of the web services layer that the consumers will use will still work for the consumer (i.e. the web services are on a different release lifecycle than the consumers and their APIs or behavior might change– they shouldn’t change wihtout notifying the consumer, but the point of this automated test is to validate that they haven’t changed)

What would I do if the web service actually executes a transaction (updates database tables). Is there a common practice for how to handle this without having to put logic into the web service itself to know its in a unit test and rollback the transaction once finished? (basically baking in the capability to deal with testing of the web service). Or is that the recommended way to do it?

The consumers are created by one development team at our company and the web services are created by a seperate team. The tests would run in an integration environment (the integration environment is one environment behind the test environment used by QA functional testers, one environment behind the prod environment)

Answer 1

The best approach to this sort of thing is dependency injection.

Put your database handling code in a service or services that are injected into the webservice, and create mock versions that are used in your testing environment and do not actually update a database, or in which you add capability of reset under test control.

This way your tests can exercise the real webservices but not a real database, and the tests can be more easily made repeatable.

Dependency injection in Java can be done using (among others) Spring or Guice. Guice is a bit more lightweight.

It may be sensible in your situation to have the injection decision made during application startup based on a system property as you note.

If some tests need to actually update a database to be valid, then your testing version of the database handling will need to use a real database, but should also provide a way accessible from tests to reset your database to a known (possibly empty) state so that tests can be repeated.