Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of bcanhome@googlemail.com
 designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGB5yNnMawo3AEOkD2TdAcA-0kXZsE2fsA91ibBy+F_B=9tqqA@mail.gmail.com>
References: <1378708575843-5738911.post@n5.nabble.com>
	<CAGB5yN=a+BAHd8iEADqZ4E98gHYQFd0sawB7C+-haVSd+S10qQ@mail.gmail.com>
	<1378742208234-5738960.post@n5.nabble.com>
	<CAGB5yNnMawo3AEOkD2TdAcA-0kXZsE2fsA91ibBy+F_B=9tqqA@mail.gmail.com>
Date: Wed, 11 Sep 2013 08:34:35 +0200
Message-ID: 
 <CAD0r13diKAG1_1bhyaON0uj6beQWSyy7ZZxOjX46Jk3RCNQKhw@mail.gmail.com>
Subject: Re: camel blueprint - unit tests
From: Achim Nierbeck <bcanhome@googlemail.com>
To: "users@camel.apache.org" <users@camel.apache.org>
Content-Type: multipart/alternative; boundary=001a11c385d49aeeb404e615d0d3

--001a11c385d49aeeb404e615d0d3
Content-Type: text/plain; charset=ISO-8859-1

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 <claus.ibsen@gmail.com>

> On Mon, Sep 9, 2013 at 5:56 PM, AlanFoster <alan@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
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>


-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>

--001a11c385d49aeeb404e615d0d3--