The runner is nearly complete, before issuing a pull request, I'd like to
discuss a few ideas and also write some more tests.
I added short readme to my forked mirror of Camel so anyone who is willing
to participate in this discussion can quickly
see what's going on.
https://github.com/josefkarasek/camel/tree/CAMEL-6070/components/camel-test
Also thanks to Williem Jiang, the camel-test-spring has been great source.
I tried to be consistent with the naming schema
defined there.
So here are few points, that I'd like to here opinion of someone else than
just me:
1. Names of annotations and packages
2. In package test4 is abstract class TestSupport.java, that defines some
static methods useful for testing (deleteDirectory
and many asserts). Since they're static, it's possible to us them even
from abstract class. My idea how to provide cleaner
way is to define new class, that will no longer be a subclass of JUnit's
Assert class (because it's not necessary any more),
will not be abstract and will facilitate only static methods. This way
you don't inherently import the whole Assert class to
every test, in stead you just use static imports of only what you need
in the test.
3. Check method annotations
(https://github.com/josefkarasek/camel/tree/CAMEL-6070/components/camel-test#2-method-annotations)
Currently those methods must not be static. If you check
camel-test-spring, annotated methods are static there.
The idea is that in JUnit static methods are called only once per test
class and non-static for every @Test method.
But unless CamelContext is created only once per test class every of the
annotated methods must be called for every
@Test, so their return values can be registered to the CamelContext -
that's why I implemented it this way. Your opinio
is welcome.
4. Is it a good idea to leave all method annotations to be optional? Simply
if user defines a method that returns RouteBuilder
and doesn't annotate it with @CreateRouteBuilder, it's still possible to
detect this method and invoke it. Only thing that
is affected by this design decision is readability of the code (and of
course one line of code per method...).
--
View this message in context:
http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192p5765921.html
Sent from the Camel Development mailing list archive at Nabble.com.
