On Mon, 22 Nov 2004 10:24:20 -0500, Erik Hatcher <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
