Follow by Email

Sunday, February 06, 2011

@RunAsJUnitTest, @RunAsPluginTest

After many idle months I'm starting to pick up work on the Workspace Mechanic for Eclipse, and that included finally publishing some of the tests that accompanied it.

And then, after starting to work on the tests some more, I realized I was missing something I used while writing plug-ins internally at Google, and so I copied them into the internal tests package. They're mostly documentation, but useful documentation. Here's the slightly reduced code for both of them. Their purpose should be clear:
 * Declares that this test can be run as a JUnit test, and does not require
 * the trappings of running as an Eclipse plug-in test.
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface RunAsJUnitTest {
* Declares that this test must be run as a plug-in test.
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface RunAsPluginTest {
Nobody likes running tests in the plug-in container if he or she doesn't have to. Surely, I'd much rather run nice fast JUnit tests, particularly when I've separated out code specifically for fast unit tests.

Of course, without infrastructure to support these, they're little more than documentation, but documentation that has type completion in the IDE.

So, what do you think? Would it be reasonable to have Eclipse support annotations like these? Do you think these have merit, or are utterly worthless?


Sebastian said...

I think that would be really helpful. Especially in combination with a continuous test-runner (e.g. infinitest), which should run only non-plugin tests.

eclipsehowl said...

Where is the bug to vote for?

yoel.abril said...

Does @RunAsJUnitTest = Junit tests and @RunAsPluginTest = Integration tests?

In my opinion is a question of structure, I'd place my junit tests inside the tested bundle and my integration tests in a fragment (or separate bundle).


David P-you know who I am said...

I'm getting deja vu all over again.

blog said...

I like the idea; we're doing something similar in our own projects. here, we have an annotation @Slow which just says: This test takes a long time.

Together with a runner, we can omit running slow tests during development and run them on the CI server.

The only drawback is that you can't mix runners; it would be great if JUnit 4 allowed to define your own "@Ignore" filters (for example: Test needs a database which is down, test needs an external framework which isn't available in this build, etc).