View source for Making your builds and tests better and faster (+ demo of JTestMe)

Facilitated by Josh Graham

== Why do we care that the are slow or bad? ==
* Very easy to calculate the cost of waiting for builds. Easily $100,000+ per annum
* Boring, frustrating
* Because consultants like Josh will laugh at us

== What makes builds slow? ==
* Infrastructure
* Compiler
* Build script
** TODO: elaborate
* Deployment
** TODO: elaborate
* Tests (see next section)
* Scary, hard-to-change (therefore you never do) build process
* Application architecture
** TODO: elaborate

== What makes tests slow? ==
* Not-really-unit tests
** Are they crossing administrative boundaries?
** Are they crossing distribution boundaries?
** Do they open an O/S resource or a database connection?
** Look at Ashcroft (but maybe not use it...)
* Heavy integration participants
** Database
** Services
* Class design
* Application architecture

== Test Less! ==
* This does not mean comment out tests because they break (lots of expletives removed)
* This does not mean deleting tests because you don't want to look after them anymore
* Remove overlapping tests (that aren’t there by design)
* Mock objects for specific interactions between collaborators
* Stubs for external integration
* Do I need to keep the test to detect regressions? Gardening of test suites to keep them optimal. Treat it as a 1st class piece of engineering.
* Smoke tests

Josh then showed a simple but effective little tool that's currently in alpha state he calls JTestMe. Jeff pointed out someone with a similar product name might object. Josh is happy to call it JediTest or just TestMe (wanted to call it TestThis!). ProTest merge is likely anyway.

Soon to be on SourceForge but currently on http://twgeeknight.googlecode.com/svn/trunk/JTestMe/