Copyright © 2004 Eclipse.org. All Rights Reserved

How to run and write AJDT Tests

last updated, October 2004.

 

The tests for AJDT are in the org.eclipse.ajdt.test plugin which can be checked out of the Eclipse CVS repository:

  • Host dev.eclipse.org
  • repository: /home/technology
  • userid: anonymous

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

Running the AJDT Automated Tests

All the automated tests are found under the testsrc package in org.eclipse.ajdt.test. To run them do the following:

  • navigate to org.eclipse.ajdt.test/testsrc/org.eclipse.ajdt.test
  • right click on AllTests.java
  • in the context menu naviage to Run and select JUnit Plug-in Test

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.

Running the AJDT Manual Tests

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:

  • build configs - this includes manual tests for the build configuration setup
  • builder - this includes manual tests specific to building AspectJ projects, when builds are automatically triggered etc.
  • documentation - these are the documentation tests which check that links work
  • editor - these tests are to do with the AspectJ editor
  • installation - these are the tests which cover the installation of AJDT under various circumstances
  • javamodel - these are the manual tests which cover the java model work, for example, what should be seen in the package explorer
  • launching - these are the tests which deal with launching AspectJ programs via the Run menu
  • project dependencies - these tests cover various setup scenarios with multiple projects
  • quick fix - these cover the quick fix facility
  • refactoring - these tests cover the refactoring capability
  • visualiser - these visualiser tests are specific to the AspectJ Provider for the visualiser. For general visualiser tests, see the visualiser test project
  • wizards - this covers manual tests required for the various wizards

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

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:

  • Create a project, say called "My AJ Project", as you would like it to be and import it into the test projects directory in org.eclipse.ajdt.test
  • At the beginning of your test include the following:
    IProject myProject = Utils.getPredefinedProject("My AJ Project", true);
    where true means that if it already exists, then overwrite.
  • Force a build of the project by calling
    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 AJDT Manual Tests

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.