pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <bri...@brindy.org.uk>
Subject Re: JUnit
Date Wed, 08 Apr 2009 08:07:31 GMT
I have no particular preference for Pivot, but will explain how I work on a
day to day basis.

Since we all use Eclipse 3.3 or 3.4, we presume that developers will have
JUnit available.  We rarely use ant to run the JUnit tests in the IDE since
the IDE has a good UI for that anyway.

In addition to the IDE our unit tests are also run by our continuous
integration (Cruise Control) which obviously already contains ant, but we
have dropped the JUnit libraries in to the ant lib folder.

In order to do a basic build of the project on a developer machine, the
developer doesn't technically need JUnit libs as we have a target that
doesn't execute unit tests.

Our setup is slightly more complicated again in that calling the default
target for the project also applies bytecode instrumentation to aid in
generating code coverage metrics before the unit tests are run, and then
rebuilds everything without instrumentation so that it can be deployed.
 Bear in mind that our projects are collections of OSGi bundles which are
Eclipse projects in their own right.  Each bundle has it's own build script
which is called from a master build script in a project build directory.

In summary ant is a system level dependency.  We also have additional tools
which are stored in source control (code coverage and osgi related), but
these may become system level as well in time.

I guess it would be good if developers can checkout Pivot and build without
having to have additional libraries.  This can be done by providing a target
which doesn't execute the unit tests.


2009/4/7 Greg Brown <gkbrown@mac.com>

> >OK, but different Eclipse versions should have different versions of
> >JUnit ... is this ok ?
> Ideally, they should be the same.
> >For tests, should we use the old 3.8.x, or (much) better one of the
> >latest 4.x (using annotations, etc) ?
> The only JUnit tests we currently have (written by Chris) use JUnit 4. I
> can't see why we would use anything earlier than this in the future.
> >All contents under test directories would be stripped out from base
> >binary jars, and if needed put in dedicated jars, right ?
> I imagine the resulting JARs would be the same as we have now.
> >In my environments I prefer to point to standard dependency jars
> >externally (for example C:\java_lib), and when required set jars in
> >the classpath from there, from IDE and from build tools.
> That would be option 2 or 3:
> http://ant.apache.org/manual/OptionalTasks/junit.html
> So, we have votes for 1, 2, 3, and 4.  :-)  Anyone else want to chime in?
> >For Ant builds the path for JUnit jar could be a key in the
> >build.properties file, so anyone could modify it as required by its
> >environment.
> Not a bad idea (though I might put it in user.properties, whose contents
> would be expected to vary from user to user).
> >And last, some tests are more visual than logic, and i don't think in
> >this case JUnit help too much ... some time ago I've seen other
> >Testing framework more UI centric, like FEST for Swing but not only (
> >http://code.google.com/p/fest/ , and
> >http://docs.codehaus.org/display/FEST/Home ).
> Yeah, JUnit won't help there. But it is certainly applicable in other
> cases.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message