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

Demo

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.

It's a few lines of AspectJ weaving and a few lines of object persistence. Blindingly fast and just what you need.

Soon to be on SourceForge but currently on Our GeekNight Google project.

Read the readme file for the background and to-do list.