Could be coding, but still can't get the tests to run. It's more fun to code, but I have to get the tests running or I can't do test-driven development. Even if I was coding first, I'd have to regression test it before I could contribute a solution in good conscience.

As I mentioned before, the main dilemma I’m struggling with has to do with whether to separate or combine the concepts of Eclipse the IDE I’m using and Eclipse the target program I’m updating. The “test.xml” file seems to want to point to a single installation with a single “eclipse-home” directory that includes all other parts as sub-directories. This doesn’t make much sense to me, as in the middle of iterative development, you’d be breaking your IDE all the time. Seeming to reinforce this, both the PDE and the CVS integration put the source and target of the Eclipse you are actively developing into a separate workspace. My assumption is that there would be two main elements in the classpath, the workspace files you are editing, and then the rest of an Eclipse installation for the other stuff.

Another possibility is that the test.xml file is targeted only for testing of a complete build, so the expectation is that you would build a complete Eclipse install with the tests included and run the test.xml from there. So the test.xml wouldn’t be useful for an iterative development experience (or at least you would have to be used to a lot of repeated builds in your iterative dev cycle.)

The gory details: When I try to run the "test.xml" file included directly in the jdt tests directory, it fails immediately, looking for a non-existent "org.eclipse.jdt.ui.tests_3.1.0" directory. The jdt tests directory I downloaded from CVS into my workspace directory does not include the embedded version string. (Though there are similar directories in the Eclipse install that do have the version string.) I start forcing the ant file to match my configuration, which means changing “eclipse-home” to my workshop directory, not my eclipse install directory, and taking the “_3.1.0” suffix away from the "org.eclipse.jdt.ui.tests” property. Then the script fails trying to find org/eclipse/core/launcher/Main. This is back in the eclipse install directory, so changing “eclipse-home” caused this problem. Hmm – this reinforces my “complete build” theory. I have two problems with that: I don’t know how to do a complete build that includes the eclipse install and all the tests I want, and even if I did, I’m more interested in iterative development testing than complete platform testing, given that the area I’m going to change is pretty small and specialized. This is worth a question to my new friends at Eclipse.

So let’s look at running jdt junit tests in isolation – the normal way to do this in Eclipse is to select the test class itself and select “run as junit test” or select a plug-in and select “run as junit plug-in test.” First, there is a project in org.eclipse.jdt.ui.tests called “test plugin.” Looks worth a try, so I select it and then select “run as junit plug-in test” and it fails almost immediately with an error: “java.lang.IllegalArgumentException: No Classloader found for plug-in org.eclipse.jdt.ui.tests.” BTW, it seems to fail this way whenever you select something that isn’t really a plug-in with this command. So much for that. OK so let’s look for a specific test to run in isolation. The test I’m most interested in is in the package “org.eclipse.jdt.ui.tests.wizardapi” and it’s called “NewTypeWizardTest.” It fails almost immediately as well, but at least gets into the junit test class and starts executing code. This is the farthest I’ve gotten, as the other two things I’ve tried get derailed by weird configuration errors before they even start (as described above). The NewTypeWizardTest routine calls something that calls the routine ResourcesPlugin.getWorkspace(), and it fails because the workspace is null, displaying the message "workspace is closed." It seems the ResourcesPlugin.startup() method needs to be called first, but it is not called. (I set a breakpoint inside it and the error hit but not the breakpoint.) By the way, this happens with all the test classes included in the “org.eclipse.jdt.ui.tests” package, including the “HelloWorld” test in the “org.eclipse.jdt.testplugin.test” package.

Is there some protocol I am not following that causes the right plug-in(s) to be initialized and started up to do these tests? I don’t see any good way to fake setting up the ResourcesPlugIn – there are warnings all over to not try to instantiate it yourself, but it obviously isn’t being instantiated.

Wrote an e-mail to Dirk and cc’ed the jdt developer list….

Dirk et al,

I’m trying to run the jdt junit tests so I can test my changes to the NewTypeWizardPage and related classes as described in bugzilla bug 108071. I’m running into roadblocks and wonder if you can give me any advice.

First, can the tests be run individually from Eclipse? Whenever I try the tests fail immediately and the cause seems to be that the “ResourcesPlugin” plug-in isn’t being initialized. (The symptom is calls to ResourcesPlugin.getWorkspace() throw a “workspace is closed” exception because the internal “workspace” variable is null, and it gets initialized in the “ResourcesPlugin.startup()” method.) Is there a formula for getting plug-in dependencies to be initialized to run a junit test? I have also tried running plug-in tests from the jdt tests directory, but these all fail even sooner with the error: “java.lang.IllegalArgumentException: No Classloader found for plug-in org.eclipse.jdt.ui.tests.”

I would much prefer to run the tests this way (meaning singly and directly from Eclipse) if possible. It is more convenient for me for iterative development.

I also tried running the “test.xml” ant script that is included in the jdt tests package, but that is failing because of path problems. It seems to want to have all the classes and tests in the same hierarchy under a single “eclipse-home” directory, and not to have a default Eclipse install with separate packages in an Eclipse development workspace. The latter is the way I have it set up, and the way the PDE and CVS integrations to Eclipse seem to steer you. Is it that you’re not supposed to use Eclipse as an IDE when you’re developing Eclipse? Or is there some step in the process I’m missing?
Please advise. Also, if this is better to be attached to the bug rather than this e-mail list, let me know. I assume I’m not the only one in the world who ever had these problems…

Thanks,
- John