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 18:47:22 GMT
Danny Angus wrote:

> 1/ Ant is the *only* sanctioned way to build James
> 2/ we should run the unit tests every time we build with ant

I've added the latter to the dist build.  I think that the overhead is
excessive during development.

> > you're talking about adding 8 minutes to every build, instead of a few
seconds.
> > doing that will cause people [to] abort the tests, and won't provide the
> > desired results.

> Agreed, therfore we need to solve *that* problem, not abandon the use
> of the tests.

No one has ever suggested abandoning the use of the tests.  The tests are
great to have, and improve (but are not sufficient to ensure) our ability to
deliver a trustworthy server

> > Show me tests that run in a few seconds instead of 8 minutes, and we
> > can talk about adding them to the build cycle.

> Sounds perfectly reasonable, and pretty much where I was trying to go with
this.

:-)

> > > One way to achieve this would be to break james out into many small
> > > library "projects"
> > So now we want to complicate the environment further to fix a spectre.
> No, it doesn't complicate things, it separates out concerns and allows
> people to focus on packages which have a single clear responsibility.

AIUI, your proposal means multiple jars (instead of just james.jar),
multiple separate components, and complicates refactoring/introduction of
new internal modules.  No?

> James is a collection of such things, mostly we don't need to build
> the whole thing over and over.

And generally we don't, although I just changed that for a dist build, which
should be built from scratch.  The topic is running tests.

Selective testing would need to know the internal dependency graph in order
to know if a change in a seemingly unrelated file requires running a test on
a given component.  Compile time and assembly level dependencies would need
to be kept in synch with the test configuration, and that doesn't include
tracking "hidden" dependencies, such as global services exposed via a
locator.  It can be done, but I'd consider it safer to just run all of the
tests, except when a developer makes a conscious decision to run just one
that he or she needs.

> In the meantime, I suggest that we do add the unit tests to the dist
target,
> and ask ourselves (social contract) to run the unit tests before
committing.

> Seems like a fine compromise.

The coding part of the plan is committed to svn.

	--- Noel



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


Mime
View raw message