How to decouple DB dependencies for web application GUI tests

WebApplication GUI testing by using Selenium API is great and important way of verifying the applications behaviour (of course only up to a specific degree). The major problem here are dependencies to other ressources which are used by other applications too. Although the application (under test) is deployed on a test plattform, other applications under test are deployed there too and are using those databases. The result here is that the tests won't work correctly since the applications will interfere each other and manipulate or delete the others test data on which they rely!

The architecture of the "enterprise" system doesn't rely on WebServices, with which one application would be able to retrieve data from another applications domain. Instead they are tightly coupled via database links by means of customized read, write execute permissions, so that each application is able to retrieve the needed data via JPA and EJB.

In order to overcome this problem I can think of the following options:

1. My favorite! For each application there exists a disinct RESTful WebService which serves as the Layer between the DB and the respective WebApplication as well as for the communication channel for dependent-by applications.

   • Pro: Utmost fexibility because it's easy to replace the dependency by a test dummy at compile time
   • Con: A lot of initial work, creation of the web service and replacement of the direct DB- access by the REST-service. As well as the maintainance of the dummy implementations.

2. The second one is to perform the test executions for the different web applications sequentially by means of a execution logic which also replaces the database (DB setup) right before the execution starts.

   • Pro: Low effort, since I only have to provide and maintain a database dump with commonly used records.
   • Con: No parallelization possible. Test execution must be scheduled. Long wait times!

3. Probably the worst one in terms of the maintainability, but I want to mention this option too since the second one may cause long idle times. So for each web application there exists a distinct test execution environment which provides all dependent databases. The database replacement works the same as described by the second approach.

   • Pro: The same as in the second approach plus a high flexibility and no wait times (scheduling), since each application has its dedicated test execution enviroment.
   • Con: Devours a lot of resources and causes a confusing test-system landscape which (probably) requires a dedicated system administrator