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 [1]

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