Difference between revisions of "Making your builds and tests better and faster (+ demo of JTestMe)"

From CitconWiki
Jump to navigationJump to search
(rv to Revision as of 13:23, 28 July 2007 by Jagraham)
 
Line 1: Line 1:
monbotadr
 
 
Facilitated by Josh Graham
 
Facilitated by Josh Graham
  
Line 34: Line 33:
 
* This does not mean comment out tests because they break (lots of expletives removed)
 
* 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
 
* 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)
+
* Remove overlapping tests (that aren’t there by design)
 
* Mock objects for specific interactions between collaborators
 
* Mock objects for specific interactions between collaborators
 
* Stubs for external integration
 
* Stubs for external integration

Latest revision as of 15:21, 3 April 2008

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.