ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: task testing style?
Date Tue, 23 Nov 2004 10:16:18 GMT



On Mon, 22 Nov 2004 10:24:20 -0500, Erik Hatcher 
<erik@ehatchersolutions.com> wrote:
 > Both styles of testing have their merits.  There are some mock objects
 > in Ant's test infrastructure (MockBuildListener, for example).
 >
 > The most important thing, of course, is that tests are created that
 > ensure that the production code is working as it should.  Sure, there
 > are more moving parts in the functional-style.  Ideally there would be
 > all flavors of testing in place to ensure all levels are functioning
 > appropriately.
 >
 > There are certainly no objections about incorporating more mock-style
 > testing into Ant's codebase.  The more testing the better!
 >
 > The dilemma I've encountered when folks catch on to mock unit testing
 > is that they get carried away with it and try to mock too much
 > functionality rather than keeping it focused, at which point you end up
 > with mock objects that are so complex that they require their own unit
 > tests :)
 >
 >         Erik
 >
 >
 >
 > On Nov 16, 2004, at 12:33 PM, Russell Gold wrote:
 >
 > > The tests I have looked at in ant appear mostly to use a semi-
 > > functional test style: they use xml to define a task, run it, and then
 > > check some results (which may simply be the lack of an error). I am
 > > used to a more unit testing style, in which external classes or
 > > subsystems are stubbed out. For example, for my dependencies task, I
 > > want to confirm that a dependency is downloaded only if it is not
 > > already present, which I do by mocking the fetch mechanism. Is this
 > > approach being used somewhere in ant? Has there been any discussion of
 > > the two approaches to testing?
 > >
 > > ---------------------------------------------------------------------
 > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
 > > For additional commands, e-mail: dev-help@ant.apache.org
 >
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
 > For additional commands, e-mail: dev-help@ant.apache.org
 >
 >

IMO, Mock objects are good for simulating failures, as there are certain 
events that are very hard to encounter in working code, but which need 
handling logic. Also they are good for offline builds.

At the same time, functional tests are good because they are, well, 
functional. We need more stuff in the ant core that goes up the chain, 
creates EAR and WAR files and then tries to work with them. What  we 
tend to do instead is rely on Gump for the advanced tests, but this has 
some problems

-Mainstream OSS projects are generally well written. We've shipped ant 
versions that work against everything in Gump, only to find some quirk 
of usage that is broken. ( I forget the details, but recall the incident)
-the gump invocation model is subtly different from in-ide or 
command-line use. Less longevity of JVMs than IDEs, overriddent 
classpaths, less chaining of build files
-everyone else gets upset when we break things.

I am busy distributing JUnit right now; so you can run test cases on 
different machines (w/ dynamic code download) and correlate the data on 
nominated systems. This is very cool, but we are still left with the 
problem of 'how do you simulate network failure'? Mock hardware, that is 
the secret. You have the entire OS hosted in a VM, hooked up to a mock 
router that you can then fiddle with to simulate different conditions 
(latency, reliability, MTU)

-steve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message