eclipse web tools
platform project
Unit Test Guidelines
This project proposal is in the Proposal Phase and is posted here to solicit additional project participation and ways the project can be leveraged from the Eclipse membership-at-large. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.webtools newsgroup or the wtp-proposal mailing list.

This document was inspired by the CDT Unit test document

1. Introduction

Is has been well proven that the time taken to write and run unit tests is recouped many times by reducing the time required to manually test, find and fix bugs. The WTP Team has adopted a policy of writing JUnit tests for WTP code in the following priority:

  • Critical and/or complex code should always have a unit test associated with it
  • Code that is found to contain an error must have a unit test created and successfully run as a requirement of closing the PR associated with the error.
  • All other code as time permits and common sense dictates

These tests will be integrated into our build process. Builds will not be marked as successful unless all unit tests, especially regression tests, run successfully. See the current Eclipse JUnit Help Pages for detailed instructions on creating and running JUnit tests within Eclipse.

In addition, the WTP Team is exploring the use of the following tools derived from JUnit. The following section on package naming conventions will hold true for tests using JDepend and/or JFunc and any other testing tools extending JUnit.

  • JDepend for generating metrics from the WTP code.
  • JFunc for creating functional tests for the WTP code.

2. WTP JUnit Test Package Naming Conventions

In order to integrate the unit tests with our build process we have proposed the following structure and format be followed by all developers writing unit tests for WTP code. Suggestions for improvements are always welcome.

Create a JUnit project for each project that you are testing. The JUnit project name should be identical to the project being tested, with the additional postfix of ".tests".

For example:

Say the classes that you are testing are contained in project named org.eclipse.wtp.tools.foobar

You would create a Java Project called org.eclipse.wtp.tools.foobar.tests

In the project "org.eclipse.wtp.tools.foobar.tests" you would create tests in package structures that mirror the packages of the classes that they are designed to test.

Say that your project contained packages called:

  • org.eclipse.wtp.tools.foobar.internal
  • org.eclipse.wtp.tools.foobar.debug

You would create corresponding packages within the test project org.eclipse.wtp.tools.foobar.tests called:

  • org.eclipse.wtp.tools.foobar.internal.tests
  • org.eclipse.wtp.tools.foobar.debug.tests

Individual tests and test suites would reside in each of the corresponding packages. Tests to test the code in org.eclipse.wtp.tools.foobar.internal would be found in org.eclipse.wtp.tools.foobar.internal.tests. Likewise, tests to test the code in org.eclipse.wtp.tools.foobar.debug would be found in org.eclipse.wtp.tools.foobar.debug.tests'. The higher level main test class "AllTests.java" would reside in the test project org.eclipse.wtp.tools.foobar.common.tests

3. References

JUnit has a plug-in that is bundled with Eclipse 2.0. It includes the following plug-ins:

  • org.junit
  • org.eclipse.jdt.junit
The main JUnit website has a wealth of information and additional QA tools.