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. */ @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.METHOD}) public @interface RunAsJUnitTest { }
/**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.
* Declares that this test must be run as a plug-in test.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface RunAsPluginTest {
}
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?
5 comments:
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.
+1
Where is the bug to vote for?
Hi,
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).
+1
Juan.
I'm getting deja vu all over again.
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).
Post a Comment