What's the JIRA ticket where I can vote for it? ;-) Best, Christian -----------------
Software Integration Specialist Apache Camel committer: https://camel.apache.org/team V.P. Apache Camel: https://www.apache.org/foundation/ Apache Member: https://www.apache.org/foundation/members.html https://www.linkedin.com/pub/christian-mueller/11/551/642 On Wed, Sep 11, 2013 at 8:55 AM, Jean-Baptiste Onofré <j...@nanthrax.net>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/<http://notizblog.nierbeck.de/2013/08/testing-camel-jpa-routes-with-pax-exam-and-karaf/> >> >> >> 2013/9/10 Claus Ibsen <claus.ib...@gmail.com> >> >> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <a...@alanfoster.me> 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<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: cib...@redhat.com >>> Twitter: davsclaus >>> Blog: http://davsclaus.com >>> Author of Camel in Action: http://www.manning.com/ibsen >>> >>> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
