You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Josef Karasek <ka...@gmail.com> on 2015/02/26 09:24:50 UTC
Would like to work on CAMEL-6070
I'm a student at a university that cooperates with Red Hat and I've been
offered ticket CAMEL-6070 as subject for thesis project.
More info:
https://diplomky.redhat.com/topic/show/212/support-for-annotation-driven-testing-in-apache-camel
I've done some studying and now I'd like to discuss my ideas to get some
feedback and also ask some questions to sort my thoughts.
General introduction:
The goal is to add a new way of configuring tests via annotations.
I expect that the targeted result is offer both ways of configuration
simultaneously without major changes to the API, only add
new feature.
My thoughts:
1) As a good place for starting things I find the setUp() method from
CamelTestSupport to be the right place.
2) It is necessary to find the class that inherits from CamelTestSupport and
defines test cases. Many libraries manipulating
bytecode at runtime can help with that
(https://github.com/ronmamo/reflections). Camel seems to already provide
some
reflection functionality in ReflectionHelper. My question here is what can I
expect from this class? I'm trying to get through it's
implementation and I don't find it to be much helpful for this purpose. As
far as I can see it's dependent on Spring. If I'm
wrong, could anyone point me to the right direciton?
Otherwise I'd like to use the library mentioned above to retrieve the
subclass with it's annotations, it's based on javassist and
has quite liberal license :-).
Thank you for your time, I'm looking forward to learning a lot from this
project.
Josef Karasek
--
View this message in context: http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Would like to work on CAMEL-6070
Posted by Josef Karasek <ka...@gmail.com>.
Working on the runner, issues how to provide customization to users have
emerged.
CamelTestSupport has plenty of methods, that can be overridden.
Because of the declarative manner of JUnit runners, providing users with
methods which they can
override is not possible and therefore the level of customization is
limited.
E.g. if user wants to create custom CamelContext or add property to the
default one.
The way that I see is to provide extra annotations, that are relevant for
testing only.
Use case #1: User wants to customize the default Context:
@RunWith(Camel.class)
public class TestCase {
@Context
public Context context;
@Before
public void usingContext() {
context.addLifecycleStrategy(myStrategy);
//Whatever you need...
}
}
Use case #2: User wants to create entirely new Context:
@RunWith(Camel.class)
public class TestCase {
@Context
public Context myContext() {
return new Context( {
// The new context
} );
}
}
CamelContext is of course just an example. There are many more objects
needed for test
customization (Template...)
*Any feedback appreciated.*
--
View this message in context: http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192p5764115.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Would like to work on CAMEL-6070
Posted by Willem Jiang <wi...@gmail.com>.
Hi Josef,
Please check out my comments in the below mail.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On April 17, 2015 at 6:01:09 PM, Josef Karasek (karasek.jose@gmail.com) wrote:
> 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
I think we can put the new added class into junit4, few people wants to use JUnit version below then 4.6 now days.
>
> 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.
>
I think we can just keep the code there, when user extends the TestSupport which inherent from Assert could save user some time to do the static imports. I don’t think it add
But I’m open to find a good way to share the static method of testing such as deleteDirectory, etc.
> 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.
I think it’s fine.
>
> 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…).
I think we should treat the @CreateRouteBuilder as the @Test annotation in JUnit4, if the user doesn’t specify it when the @UseRouteBuilder is not false, the runner should complain about it.
>
>
>
> --
> 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.
>
Re: Would like to work on CAMEL-6070
Posted by Josef Karasek <ka...@gmail.com>.
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.
Re: Would like to work on CAMEL-6070
Posted by Willem Jiang <wi...@gmail.com>.
If you take a look at the codes of camel-test-spring, you can find there are some annotations with does the work that you want to do.
I think you just need to turn it into more generic way and reuse it in side of JUnit Runner.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On February 27, 2015 at 8:16:16 PM, Josef Karasek (karasek.jose@gmail.com) wrote:
> Thank you for your reply.
>
> I'll work on the JUnit custom test runner.
>
> But I still have a few questions:
> How can I find "if we want to support annotations for test class extending
> CamelTestSupport"?
>
> If the answer is yes, we want to do that, I don't find the standard Java
> Reflection API much of a good use since it loads all
> classes being inspected to JVM's memory, whereas the ReflectionS API (the
> github link) does not. Wouldn't the higher memory
> footprint be an issue?
>
> Thank you in advance.
> Josef Karasek
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192p5763255.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: Would like to work on CAMEL-6070
Posted by Josef Karasek <ka...@gmail.com>.
Thank you for your reply.
I'll work on the JUnit custom test runner.
But I still have a few questions:
How can I find "if we want to support annotations for test class extending
CamelTestSupport"?
If the answer is yes, we want to do that, I don't find the standard Java
Reflection API much of a good use since it loads all
classes being inspected to JVM's memory, whereas the ReflectionS API (the
github link) does not. Wouldn't the higher memory
footprint be an issue?
Thank you in advance.
Josef Karasek
--
View this message in context: http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192p5763255.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Would like to work on CAMEL-6070
Posted by Willem Jiang <wi...@gmail.com>.
With the help of @RunWith from JUnit you can inspect the test class with the annotation in you custom runner. So we don’t need to ask the user to extend the CamelTestSupport anymore.
If we still want to support the annotation for the test class which extends CamelTestSupport, we just need find a way to check the annotation with the reflection APIs.
ReflectionHelper just provides some callbacks for you to inspect the annotations on the filed or the method, maybe we need add a new method for inspecting the annotation of the class.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On February 26, 2015 at 4:25:17 PM, Josef Karasek (karasek.jose@gmail.com) wrote:
> I'm a student at a university that cooperates with Red Hat and I've been
> offered ticket CAMEL-6070 as subject for thesis project.
> More info:
> https://diplomky.redhat.com/topic/show/212/support-for-annotation-driven-testing-in-apache-camel
>
> I've done some studying and now I'd like to discuss my ideas to get some
> feedback and also ask some questions to sort my thoughts.
>
> General introduction:
> The goal is to add a new way of configuring tests via annotations.
> I expect that the targeted result is offer both ways of configuration
> simultaneously without major changes to the API, only add
> new feature.
>
> My thoughts:
> 1) As a good place for starting things I find the setUp() method from
> CamelTestSupport to be the right place.
> 2) It is necessary to find the class that inherits from CamelTestSupport and
> defines test cases. Many libraries manipulating
> bytecode at runtime can help with that
> (https://github.com/ronmamo/reflections). Camel seems to already provide
> some
> reflection functionality in ReflectionHelper. My question here is what can I
> expect from this class? I'm trying to get through it's
> implementation and I don't find it to be much helpful for this purpose. As
> far as I can see it's dependent on Spring. If I'm
> wrong, could anyone point me to the right direciton?
>
> Otherwise I'd like to use the library mentioned above to retrieve the
> subclass with it's annotations, it's based on javassist and
> has quite liberal license :-).
>
> Thank you for your time, I'm looking forward to learning a lot from this
> project.
> Josef Karasek
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Would-like-to-work-on-CAMEL-6070-tp5763192.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>