A real camel-test component for Camel 2.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A real camel-test component for Camel 2.0

Claus Ibsen
Hi

I am writing on another tutorial and is showing how to use plain spring test support classes for easier junit testing. And the spring .jars is real jars (not test-jar).

I am thinking that we should for Camel 2.0 also create a real camel-test component that holds the test support classes end-users and camel itself can use for unit testing.

Now these test support classes is mixed with the unit test classes themselves.

Then end users can just depend on camel-test in their maven repo and it's a more elegant. Also the camel-test.jar will not be cluttered with all kind of leftovers from our unit tests. For instance log4j.properties, jndi.properties and whatnot we have got have there.

Any thoughts?

I think it's a good idea to get in Camel 2.0 from the start before the API and what else is locked. Then instead of relying on camel-spring test-jar or camel-core test-jar then end-users should migrate by switching to camel-test.

Is there any problem if camel-test will support both plain java tests or the spring ones as well?



Med venlig hilsen

Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

Reply | Threaded
Open this post in threaded view
|

Re: A real camel-test component for Camel 2.0

Willem.Jiang
Administrator
Hi Claus,

+1 for creating a real camel-test component for Camel 2.0.

If we create a real camel-test component with current Camel modules
layout,  it will introduce the cycle dependency into the camel-core
camel-test <--> camel-core
Maybe we could take out the camel-api for the camel-core to resolve this
cycle dependency.
camel-api <-- camel-test <-- camel-core

And there are lots of test cases in the
org.apache.camel.spring.processor package of the camel-spring-test.jar
which extents the test classes in the camel-core-test.jar, it is a
challenge for us to support this kind of code reuseability  in the new
camel-test component.

Any thoughts?

Willem
 
Claus Ibsen wrote:

> Hi
>
> I am writing on another tutorial and is showing how to use plain spring test support classes for easier junit testing. And the spring .jars is real jars (not test-jar).
>
> I am thinking that we should for Camel 2.0 also create a real camel-test component that holds the test support classes end-users and camel itself can use for unit testing.
>
> Now these test support classes is mixed with the unit test classes themselves.
>
> Then end users can just depend on camel-test in their maven repo and it's a more elegant. Also the camel-test.jar will not be cluttered with all kind of leftovers from our unit tests. For instance log4j.properties, jndi.properties and whatnot we have got have there.
>
> Any thoughts?
>
> I think it's a good idea to get in Camel 2.0 from the start before the API and what else is locked. Then instead of relying on camel-spring test-jar or camel-core test-jar then end-users should migrate by switching to camel-test.
>
> Is there any problem if camel-test will support both plain java tests or the spring ones as well?
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: A real camel-test component for Camel 2.0

jstrachan
In reply to this post by Claus Ibsen
2008/9/7 Claus Ibsen <[hidden email]>:
> Hi
>
> I am writing on another tutorial and is showing how to use plain spring test support classes for easier junit testing. And the spring .jars is real jars (not test-jar).

Awesome!

> I am thinking that we should for Camel 2.0 also create a real camel-test component that holds the test support classes end-users and camel itself can use for unit testing.
>
> Now these test support classes is mixed with the unit test classes themselves.

To be honest, I think lots of that testing code can be retired over
time and replaced with the neater new spring stuff really.  Or to say
that another way; I'm not sure how much code we really need to do
testing other than using the nice injection stuff & MockEndpoints with
the spring-test stuff. Though we could do with something to test
non-spring I guess (maybe Guice?).

I did start the camel-hamcrest module with the intention of adding
extensions to the hamcrest testing mechanism so you can kinda write
assertions using a kinda Java DSL that is self commenting; so when the
assertion fails you get great error messages. Am sure we could do
better in that area maybe.


> Then end users can just depend on camel-test in their maven repo and it's a more elegant. Also the camel-test.jar will not be cluttered with all kind of leftovers from our unit tests. For instance log4j.properties, jndi.properties and whatnot we have got have there.
>
> Any thoughts?

Agreed. Maybe to start with we should ponder if folks use spring and
the spring testing stuff
http://activemq.apache.org/camel/spring-testing.html

what else to we really need?

> I think it's a good idea to get in Camel 2.0 from the start before the API and what else is locked. Then instead of relying on camel-spring test-jar or camel-core test-jar then end-users should migrate by switching to camel-test.
>
> Is there any problem if camel-test will support both plain java tests or the spring ones as well?

I've always tried to keep camel-core free of any spring dependencies
as there are numerous IoC frameworks folks tend to like; though spring
is the most common one folks use. So I guess being spring dependent is
no biggie. Though we might wanna do a Guice one too :)

The base classes for things like ContextTestSupport is handy if you're
not using spring though. But I think the IoC/spring-test approach is a
bit cleaner and avoids having to extend from camel specific base
classes for tests etc. If using JUnit 4 or TestNG there's no need for
a base class at all

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: A real camel-test component for Camel 2.0

jstrachan
In reply to this post by Willem.Jiang
2008/9/7 Willem Jiang <[hidden email]>:

> Hi Claus,
>
> +1 for creating a real camel-test component for Camel 2.0.
>
> If we create a real camel-test component with current Camel modules layout,
>  it will introduce the cycle dependency into the camel-core
> camel-test <--> camel-core
> Maybe we could take out the camel-api for the camel-core to resolve this
> cycle dependency.
> camel-api <-- camel-test <-- camel-core
>
> And there are lots of test cases in the org.apache.camel.spring.processor
> package of the camel-spring-test.jar which extents the test classes in the
> camel-core-test.jar, it is a challenge for us to support this kind of code
> reuseability  in the new camel-test component.

Yeah - to do a kinda regression test, I started deriving the spring
tests from the core tests but using spring rather than the Java DSL -
though I do find all that code a tad smelly :)

Apart from those tests, the camel-spring module should ideally just
use the spring-test stuff; so it doesn't really need any code from
camel-core-test or anything.

If we did introduce a camel-test library, we'd not have to use it in
camel-core or camel-spring I don't think; we could always move tests
outside those 2 modules. Plus there's nothing stopping us having
separate modules to test various things in the build.

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: A real camel-test component for Camel 2.0

jstrachan
2008/9/8 James Strachan <[hidden email]>:

> 2008/9/7 Willem Jiang <[hidden email]>:
>> Hi Claus,
>>
>> +1 for creating a real camel-test component for Camel 2.0.
>>
>> If we create a real camel-test component with current Camel modules layout,
>>  it will introduce the cycle dependency into the camel-core
>> camel-test <--> camel-core
>> Maybe we could take out the camel-api for the camel-core to resolve this
>> cycle dependency.
>> camel-api <-- camel-test <-- camel-core
>>
>> And there are lots of test cases in the org.apache.camel.spring.processor
>> package of the camel-spring-test.jar which extents the test classes in the
>> camel-core-test.jar, it is a challenge for us to support this kind of code
>> reuseability  in the new camel-test component.
>
> Yeah - to do a kinda regression test, I started deriving the spring
> tests from the core tests but using spring rather than the Java DSL -
> though I do find all that code a tad smelly :)
>
> Apart from those tests, the camel-spring module should ideally just
> use the spring-test stuff; so it doesn't really need any code from
> camel-core-test or anything.
>
> If we did introduce a camel-test library, we'd not have to use it in
> camel-core or camel-spring I don't think; we could always move tests
> outside those 2 modules. Plus there's nothing stopping us having
> separate modules to test various things in the build.

BTW it might actually simplify some of the tests for the Java DSL v
spring v scala (v other DSLs) to move some of those regression tests
using different DSLs into a separate module; so all the tests stay
together

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com