Hi There is already itests for Karaf with pax-exam in Camel, in the tests/camel-itest-osgi directory. As an end user wanted to do this, this is not so easy as there is fair amount of setup to do and whatnot. The JIRA ticket I mentioned was to polish this and turn that into a end user component, camel-test-karaf, and with good documentation to go with that.
Then people can easier do this than today. Where they can copy some of the source code from tests/camel-itest-osgi and use that in their own pax-exam karaf tests of their Camel integration tests. On Wed, Sep 11, 2013 at 8:55 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Agree with Achim, it's something that I plan for Camel (and other projects > like ActiveMQ): pax-exam with the Karaf container allows good itests. > > We use it for Cellar: the itests, we can bootstrap a Karaf container, > perform commands, check the result, etc. > > Regards > JB > > > On 09/11/2013 08:34 AM, Achim Nierbeck wrote: >> >> wow, now that is something I call a rant :D >> >> anyhow, you're only telling half the truth ;) >> yes developing osgi might be cumbersome but to be hones EJB is the same >> PITA >> and I really hated working with JBoss and maven when I needed to work with >> EJBs, >> the turnaround cycles where awful and to me much better when developing >> with Karaf and >> dev:watch especially. (Sorry needed to rant about some EJB stuff too:) ) >> Anyway the unit-test with camel-blueprint are good but lack the support >> for >> JPA stuff >> as it uses PojoSR wich just fails with the JPA stuff, and every now and >> then you >> just need to have this tested to so it fails. >> About the Integration tests, we do have Pax-Exam at this point and it does >> an >> awful great job for testing also with Karaf as container. >> And you might even are able to use this peace of Testing Framework for >> your >> unit >> tests. I wrote a little blog entry about it at [1]. >> >> At the end you'll always end up in the same situation with any container >> (may it be a >> JBoss, Tomcat or Karaf) you'll need some unit tests and some Integration >> Tests. >> And sometimes you want to have Integration tests that do work from the >> inside of >> the container not testing the outer interfaces but test some aspects from >> Inside the container >> and this is the point Pax-Exam comes real handy also for JBoss or Tomcat, >> just take a >> look at the latest versions. >> >> regards, Achim >> >> [1] - >> >> http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/ >> >> >> 2013/9/10 Claus Ibsen <[email protected]> >> >>> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <[email protected]> wrote: >>>> >>>> @Claus - This is true when deployed to an OSGi container. However, >>> >>> within the >>>> >>>> context of camel testing this is not true. When using the camel testing >>>> framework you need to supply all of the camel routes within your >>>> `getBlueprintDescriptor` >>>> >>>> @fs I just wanted to add; In my experience i have found it is safer to >>> >>> test >>>> >>>> your deployed camel app end to end, and not rely on CamelBlueprintTests >>> >>> much >>>> >>>> - as they do not prove that your app will work when deployed to an OSGi >>>> container, or work at runtime when deployed to a real OSGi container. >>>> >>> >>> camel-test-blueprint is not a substitute for integration testing on >>> the actual production like servers. >>> IMHO you must always do this to ensure it works on your production >>> environment. >>> >>> camel-test-blueprint makes development with blueprint much easier as >>> you can do much quicker Camel development, and unit tests. And you can >>> do debugging the same JVM etc. And much more. >>> >>> Doing development and running in Karaf is a pain. Even with the >>> dev:watch command. >>> IMHO camel-test-blueprint is a huge win, and I know some companies of >>> ours that would hate us if we do not offer camel-test-blueprint. That >>> said, the OSGI communities should making development with OSGi much >>> easier and a pleasure, instead of what the state is here in the later >>> half os 2013 currently is. >>> >>> Okay my development with OSGi is hard, rant is over (") comparing to >>> what the norm is today. >>> >>> PS: Thought this reminds me, that we ought to offer a camel-test-karaf >>> which makes doing integration testing with Karaf and Camel easier. We >>> do have some code in tests/camel-itest-karaf we would need to dust off >>> and make nicer, and as well document. There is a JIRA ticket for that. >>> >>> Again devlopment + unit test vs integration testing is IMHO two pieces >>> that you need to have. But the former should be very easy to do, and >>> camel-test-blueprint helps alot with that. Though unfortuntely it >>> cannot do 100% the same as Karaf container so there can be some cases >>> where you currently must deploy to karaf to do unit test also :( >>> >>> >>> >>>> >>>> >>>> -- >>>> View this message in context: >>> >>> >>> http://camel.465427.n5.nabble.com/camel-blueprint-unit-tests-tp5738925p5738960.html >>>> >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> Red Hat, Inc. >>> Email: [email protected] >>> Twitter: davsclaus >>> Blog: http://davsclaus.com >>> Author of Camel in Action: http://www.manning.com/ibsen >>> >> >> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
