Home/ Questions/Q 937523
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T21:29:36+00:00

I’m working on an existing Java EE project with various maven modules that are

  • 0

I’m working on an existing Java EE project with various maven modules that are developed in Eclipse, bundled together and deployed on JBoss using Java 1.6. I have the opportunity to prepare any framework and document how unit testing should be brought to the project.

Can you offer any advice on…

  • JUnit is where I expect to start, is this still the defacto choice for the Java dev?
  • Any mocking frameworks worth setting as standard? JMock?
  • Any rules that should be set – code coverage, or making sure it’s unit rather than integration tests.
  • Any tools to generate fancy looking outputs for Project Managers to fawn over?

Anything else? Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Any tools to generate fancy looking outputs for Project Managers to fawn over?

    Be careful. A fancy tool for displaying metrics on unit test counts, coverage, code quality metrics, line counts, check-in counts and so on can be dangerous in the hands of some project managers. A project manager (who is not in touch with the realities of software development) can get obsessed with the metrics, and fail to realize that:

    • they don’t give the real picture of the project’s health and progress, and

    • they can give a completely false picture of the performance of individual team members.

    You can get silly situations where a manager gives the developers the message that they should (for example) try to achieve maximal unit test coverage for code where this is simply not warranted. Time is spent on pointless work, the important work doesn’t get done, and deadlines are missed.

    Any rules that should be set – code coverage, or making sure it’s unit rather than integration tests.

    • Code coverage is more important for parts of the code that are likely to be fragile / buggy. Acceptable coverage levels should reflect this.

    • Unit tests versus integration tests depends on the nature and complexity of the system you are building.

    • Adding lots of unit level tests after the fact is probably a waste of time. It should only be done for class identified as being problematic / needing maintenance work.

    • Adding integration level tests after the fact is useful, especially if the projects original developers are no longer around. A decent integration test suite helps to increase your confidence that some change does not break important system functionality. But this needs to be done judiciously. A test suite that tests the N-th degree of a website’s look and feel can be a nightmare to maintain … and impediment to progress.

    • 0