Question

My Spring web project consists of:

  1. util classes;
  2. repositories;
  3. services;
  4. controllers.

The tests are as follows:

  1. unit tests for util classes;
  2. spring integration tests for repositories with HSQLDB;
  3. unit tests for services with mock repositories;
  4. unit tests for controllers with mock services.

There also may be system tests which test the overall project functionality. It can be performed with an external tool like Selenium or it can be performed using Spring integration testing.

The question is, should I include such spring integration system tests in a project or should they be separated somehow?

I see two problems about including system tests in a project: 1. they need configuration tuning because such tests will not run with production config (e.g. tests need a local datasource, not the one from JNDI); 2. they aren't autonomous, they need some external resources and so on. I cannot just run them as usual unit tests.

How do you organize your system testing?

Was it helpful?

Solution

On small projects I've kept them in the same place. On large enterprise projects (the kind for which you might usefully leverage Spring, for instance) we've usually organised system tests in a separate package / project. This helps keep them separate from the main codebase.

If you don't do this, there's all kinds of temptation to reuse classes from the code to "help out" in something which should be more strongly focused on the experience of users of the system (a user may be another system). If this happens, you end up with coupling between the project domain classes and the UI, which will have the inevitable effect of needing to duplicate much of the logic which helps keep them decoupled in the real codebase.

Most of the time the logic in system scenarios will actually be focused on pages, screens, web-calls, etc. so reusing code from the main project is a red herring. Keep the packages separate to avoid this happening, and because once you avoid it happening there's no need to have them in the same place.

Do, however, make sure that the system tests are checked in to the same version control as the code.

If you're not doing continuous integration and testing / deployment yet, that might be another area for which some learning will help you with the config files. That problem doesn't go away just because you have tests in a separate project, unfortunately.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top