james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [DISCUSSION] Include Unit Tests in regular build
Date Sat, 11 Nov 2006 15:57:50 GMT
> To make everyone happy, why not have a default goal, which runs tests,
> builds james, etc.  And one goal which compiles james too, just without
> the tests.

For what benefit?  How hard would it be to run `ant dist-liter` instead of
`ant`.  That doesn't address the "problem", if there even is a problem (I
don't believe that there actually is one).

I do suggest that we add the unit tests to the dist target, which is the one
that builds the packages.

> That way non-IDE Developers, using only true editors and the command line,
> compile without the tests to see if their modifications compile.  Before
> check-in they should run ant again with the default goal

Why would this happen with any more frequency than `ant run-unit-tests`?
Either one requires a specific action that is additional to the build

> If the tests failed, he can examine which test failed an run this test
> alone. Modify his source, run it alone until it passes.

Or the test.  As we've seen, sometimes it is the test that is broken.  And
we still need to add support for running individual tests, e.g.,

  ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest

> ... and everyone is happy for a, long believed not to be there, memory
leak fix.

Totally unrelated to this discussion.  That memory leak would not have been
detected by unit tests, at least not as we have them.  Testing that would
have required simulating connections from many separate IP addresses, and a
fake DNS provider inserted underneath java.net.InetAddress.  Or a more
thorough audit of the code, perhaps with a DNS provider that warns that it
is called at all.  Over-reliance on unit tests and presumption that if it
didn't occur in their environment then it didn't exist is why no one else
believed that it existed at all.  What resolved that problem was my
personality in the face of everyone else wanting to close the bug as
invalid, and my performing extended heap evaluations on a production server.

	--- Noel

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

View raw message