Making JUnit tests

The first rule if you're making or running JUnit tests for Eclipse code is you have to download the source for the org.eclipse.test.performance package. This magically enables JUnit plug-in tests to work, and without it, you get a bunch of inexplicable errors that you will waste your time trying to understand and fix.

Since this was the first time I ever made up a new JUnit plug-in test, I looked at other examples in the org.eclipse.jdt.ui.tests package. I had added tests to the NewTypeWizardTest before, I poked around in there for ideas, and it helped to review familiar territory.

The main issues with testing Eclipse code are having the right interfaces to test what you need, and getting the classes you want to test into the right state. Since these classes normally execute inside complex Eclipse runtime contexts, you have to do some experiments with setting up scaffolding and calling initialization methods. When you need test projects to work with, you can create them inside the setUp() method of the JUnit test. Since Markus told me he didn't want me actually running a JUnit test and checking to see if it actually asserted, but only checking if the launch configuration was initialized correctly, I didn't have to bother with setting up a test project to run. I could test each unit on a lower level.

The units of functionality I had to test were:
That the preference for enabling assertions was initially false
That enabling and disabling the checkbox on the preferences page properly set and cleared the enable assertions preference
That the preference caused new launch configurations to be initialized properly (JUnitTabGroup) with the assertion VM arg or not
The automated tests for default configuration creation (JUnitWorkbenchShortcut) and plug-in test initialization (AbstractPDELaunchConfigurationTabGroup) I left out because they looked like more trouble, so I hope I don't burn in hell too long for that.

The first test was a no-brainer, just put an assertion on the utility function for reading the preference to make sure it's off.

The second test for the preferences page had two issues. First, since you don't test by means of a UI robot, but test by means of calling utility methods on the page, I had to create a utility method to set and clear the check box. Second, you have to create a page and initialize it to test it. In the case of a JUnitPreferencesPage, I had to call the createControl() method to initialize the SWT widgets so I could set and clear the checkbox. The createControl() method needs an SWT UI context as the parent of the new page. Luckily, the JUnit plug-in scaffolding provides a DialogCheck class that has a getShell() method you can use as a parent context. After creating a new page and initializing it this way, all I had to do was call my checkbox enable/disable method, call the page's performOk() method, and assert that the preference had been set correctly.

The third test for the launch configuration initialization took more experimenting. First, you can’t change a launch configuration, so you have to use a launch configuration working copy. And you can’t instantiate one; you have to go through a 4-line song-and-dance that I put into a utility method. Then, you have to create a tab group and initialize it using createTabs(). Then you can call the setDefaults() method on the tab group, and then test to see if the launch configuration has the assertion enabling argument on or not as expected.