Question

Environment:

• Java
• Maven
• Eclipse
• Spring
• Jetty for developemnt
• JUnit

I just started on a new project (Yay!) but the current unit test state is a bit strange (to me). There is no way to run the tests in an automated way. Some of the tests need the server up and running to pass and so fail when run otherwise.

To make matters worse there are a large number of tests that have fallen behind and no longer pass, though they should (or they should have been changed).

The trouble is that the tests are run manually (right click in eclipse and run as JUnit test) so since no-one is going to manually test everything with each change the tests are simply written and then forgotten.

I am used to developing with all tests green from the start and I want to bring testing back into a useful state with automation.

How do I:

• Mark test to not run with a reason (like “legacy test needs to be updated” or “passes only with server”).
• Run different tests depending on if the server is up.
• Some way to log test statistics for trending of testing information (not as important)

Any suggestions would be useful. Thanks.

Update: made question more specific.

Answer 1

Assuming you’ve got actual work to be getting on with, I’d advise not to try to fix all of the existing tests before doing anything else. By all means @Ignore any tests that are failing so you can work with the tests that currently pass. Maybe also try to make a note for each failing test that you ignore, so you can re-visit it when you come to work on the area of code it’s trying to test.

If your tests depend on external services, you may be able to use assumeTrue() to verify that they’re up before actually trying and failing the test — this will mark the test ignored at run-time so you still get your build and as much useful information as is possible. The TestWatcher class (if you have a new enough JUnit) may help you to do this with minimal boilerplate — we have it set up to ignore instead of failing if we can’t connect, then to ignore any tests that would subsequently fail without paying the timeout penalty again.