directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Taylor <nega...@freesurf.ch>
Subject Re: [Testing] Coping with so many integration tests
Date Tue, 06 Feb 2007 20:35:53 GMT
I had similar issues with using Apache DS for tests in the Acegi
Security project. We have a single embedded test server

http://monkeymachine.co.uk/acegisecurity/acegi-security/xref-test/org/acegisecurity/ldap/LdapTestServer.html#47

which is accessed through a static variable on the base test class

http://monkeymachine.co.uk/acegisecurity/acegi-security/xref-test/org/acegisecurity/ldap/AbstractLdapServerTestCase.html#44

It's not a very tidy solution but it does mean the server is only
started once during the test run since Maven 2 uses a single classloader
to run all the tests (unlike some other Junit test runners which reload
the class for every test method!). We only need read access to the data
from the tests so there's no problem of side effects between them, but
it would presumably be possible to clean the data in setUp() and
tearDown() methods and still save the server startup overhead.

Luke.


Alex Karasulu wrote:
> Hi,
> 
> The number of integration tests are growing large (we have hundreds) as
> we get more coverage for the server and the functionality increases.
> These tests start and stop apacheds and clean out working directories on
> each run so they can take a while especially if a test case has lots of
> tests in it.
> 
> I have two ideas on how to ameliorate these problems.  One is short term
> and the other long term.
> 
> First the short term solution.  I found that I can create large 512K ram
> drives (do not try more than 512K it does not work) then combine them
> together using RAID to make a large disk.  After having done this test
> case classes that took 20 seconds started to take 4 seconds instead. Not
> bad but still not ideal since we have so many tests.  This however does
> not have that many drawbacks besides still taking 9 minutes and 49
> seconds to run all the integration tests.
> 
> Long term solution:  See if we can modify the surefire plugin for
> distributed operation.  It would be easy to have a java daemon that can
> run maven on various projects.  Commands can be sent to this to setup
> and run individual test case classes.  The distributed surefire plugin
> would simply queue operations and collect the results from several
> machines.  This way you get serious parallelism especially if you have
> many machines.  With four machines the time could be cut down to 2 and a
> half minutes.
> 
> Thoughts?
> 
> Alex

-- 
 Luke Taylor.                      Monkey Machine Ltd.
 PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk


Mime
View raw message