Copyright © 2004 Eclipse.org.
All Rights Reserved
The tests for AJDT are in the org.eclipse.ajdt.test plugin which can be checked out of the Eclipse CVS repository:
Once connected, navigate to HEAD > org.eclipse.ajdt and checkout the plugins in the AJDT1.2src directory.
This document describes how to run and write both automated and manual AJDT Tests. Note that at the moment there is only one test plugin which contains tests for both the ui and core which are now separated into the org.eclipse.ajdt.ui and org.eclipse.ajdt.core plugins respectively. Our plan is to move to having separate test plugins, one for the ui and one for the core functionality.
Running the AJDT Tests |
All the automated tests are found under the testsrc package in org.eclipse.ajdt.test. To run them do the following:
This launches the AJDT automated testsuite.
To monitor the progress of the tests, or to see the results, open the JUnit view. If you want to run a specific test, or testcase, then follow the same steps above, except this time navigate in the package explorer to the testcase or test you wish to run.
As the tests run, output is sent to the console. In all cases, if the output isn't expected for the test, then the test will fail. However, occasionally, due to timing issues and scheduling of jobs in Eclipse 3.x, a couple of the tests may fail. We are currently looking into making these tests more robust, but for the time being, rerun the failing tests when little other work is going on on your machine and if they pass then assume everything is ok. Occasionally, Resource Exceptions are seen with problems deleting resources. Deleting projects is not part of the tests, instead it is part of the clean up, and so these can be ignored as not affecting the test run. Problems deleting resources within AJ projects are being looked at in bug 75776.
Note that many of the automated tests use the test projects contained in the test projects directory in the org.eclipse.ajdt.test plugin.
There are also a set of manual tests to run against AJDT. These are found in the manual testing directory of the org.eclipse.ajdt.test plugin. The tests have been split into the following categories:
There are also a few other manual tests, not put into a category, which are also run.
To run any of these tests, follow the instructions set out in the script. In many cases, the tests use projects contained in the test projects directory in the org.eclipse.ajdt.test plugin. These tests can be checked out as projects from cvs.
Writing AJDT Tests |
Writing AJDT Automated tests is no different to writing JUnit tests for any other project. We stay as close as we can to the convention that the package structure under testsrc mirrors that of the org.eclipse.ajdt.ui and org.eclipse.ajdt.core plugins, with the testcase classes being named as < Class to be tested >Test.java.
A utility has been written to make it easier to create projects to use as part of the testing. This enables you to create the project, check it into CVS under the test projects directory and then import it in your automated test (this prevents a lot of the scheduling issues which happen due to the background running of many jobs in Eclipse 3.x). We recommend that you use this in your automated tests. To make use of this feature, do the following:
IProject myProject = Utils.getPredefinedProject("My AJ Project", true);where true means that if it already exists, then overwrite.
myProject.build(IncrementalProjectBuilder.FULL_BUILD, null);and off you go!
One other point to note when writing AJDT automated tests is to at the beginning of the test unset the requirement for the user to respond to the AJDT Configuration Wizard and to reverse this before exitting the test (this requirement should be removed as we become more closely integrated with JDT). In otherwords, place the following at the beginning of your test:
AspectJPreferences.setAJDTPrefConfigDone(true);and then
AspectJPreferences.setAJDTPrefConfigDone(false);at the end.
Finally, if the test has been written in response to a bug, then note the bug number in the comment above the test.
Writing manual tests is pretty straightforward. Just decide on the appropriate section, create a .txt file with an appropriate title (or add to an existing one) and write down the steps needed to be followed to run the test. In all cases, ensure that someone can follow the steps from scratch, including getting hold of the projects required for the test. If you need to create new projects, then place them in the test projects directory so that they're easy to access. If the test is in response to a bug fix, then note the bug number at the top of the test.