test execution times

Lukas Krejci lkrejci at redhat.com
Wed Dec 19 16:35:52 UTC 2012


Oh, I didn't know that..

Still having the debugger attached to the remote container offers some benefits:

* 4-5 seconds of AS7 startup shaved off each test run (the deployment needs to 
be done anyway and this could only be helped by jsanda's modularization of the 
server/jar (and I am not convinced we'd see much reduction there given the 
number of inter-deps amongst our SLSBs - but I certainly hope John will prove 
all of us skeptics wrong))
* No need to re-attach the debugger each time you run the test

But these are not something I'd call major...

On Wednesday, December 19, 2012 10:12:06 Jay Shaughnessy wrote:
> For eclipse users we already have a test debug configuration for this in
> the drop down list.  You can use -Dtest.debug and -Ditest.debug to set
> breaks in the code creating the deployment, and the actual
> deployment/tests, respectively.
> 
> On 12/19/2012 7:47 AM, John Mazzitelli wrote:
> > -Ditest.debug will run the arquillian stuff such that you can attach a
> > debugger to it over port 8798 (I think that's the port number).
> > 
> > ----- Original Message -----
> > 
> >> On Tuesday, December 18, 2012 14:49:04 Jay Shaughnessy wrote:
> >> 
> >> ... snip ...
> >> 
> >>>> 2) Use remote container instead of managed container
> >>>> Arquillian handles starting and stopping a managed container
> >>>> whereas
> >>>> the lifecycle of a remote container is not handled by Arquillian.
> >>>> I
> >>>> kept my AS 7 instance running. Maybe Jay and/or Mazz have some
> >>>> insights into whether or not there might be issues with using a
> >>>> remote
> >>>> container.
> >>> 
> >>> Certainly using a running remote server can speed things up since
> >>> it
> >>> avoids that setup/teardown, although I suspect it can affect a lot
> >>> of
> >>> the tests as written today, given that many freely perform
> >>> transaction
> >>> management and interact with the entitymanager.
> >>> 
> >>> I have nothing against doing this when it make sense.  Perhaps you
> >>> could
> >>> give us some instructions if you have this working for certain
> >>> tests.
> >>> 
> >>>   From the perspective of jenkins CI runs the managed container
> >>>   certainly
> >>> 
> >>> makes sense.
> >> 
> >> http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/integration-
> >> tests/jndi-access/jndi-access-test/pom.xml#n152
> >> 
> >> E.g. Jenkins does "mvn clean install" and gets the managed server.
> >> You as a
> >> developer do "mvn clean install -Premote-test-server" and run your
> >> test on the
> >> pre-started AS7 with a debugger attached. There are 2 pros to this:
> >> 1) you
> >> don't get the overhead of starting and stopping the full server for a
> >> single
> >> test run, 2) You can actually debug your test code ;)
> >> 
> >> I tried a similar approach in itests-2 module and for some reason it
> >> didn't
> >> work that well - but I didn't spend too much time on it since I knew
> >> we were
> >> making big changes in the module and its pom at that time so I kinda
> >> let it be
> >> and concentrated on other things.
> >> 
> >> But given how small those profiles are and how much utitility they
> >> provide I'd
> >> be very much for including something like this more "globally" in the
> >> build
> >> (if we manage to make it work everywhere)...
> >> 
> >> 
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list