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

From CitconWiki
Jump to navigationJump to search

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.