Testing Presentations

Their has been a presentation I watched last year that absolutely changed my opinion on how I tested and how I designed.  It was one of those presentations that just made sense and I cant believe I haven’t blogged about it until now.

Integration Tests are a Scam by Joe Rainsberger

This was my favourite presentation from last year. It talks about writing the correct type of unit tests to get get fast results and reduce the need for slower integration tests that are generally slower are require a lot of maintenance. He makes a compelling argument about the number of tests in your system don’t improve the sense of security you get from your tests by the same amount. So he talks about what needs to be unit tested from the contract class and the opposite collaborator class and how doing so gives you a better picture of what tests you need to give you a sense of security with quick feedback. The blurb explains it better

Integration tests are a scam. You’re probably writing 2-5% of the integration tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integration tests probably duplicate each other all over the place. When an integration test fails, who knows what’s broken? Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.


TDD of Asynchronous Systems

This presentation by the author of a new book, “growing object oriented software, guided by tests” Nat Pryce, which talks about testing at the integration/functional level and techniques to get around all the painful ‘flickering tests’ & ‘false positives’ issues that occur when you have them. The examples talk about testing legacy systems, swing gui’s and JMS queues.

One of the key ideas is that one must find a point to synchronise on before executing the assertions and those assertions must wait (and retry if not true) until the state has changed or a timeout occurs (and the test then fails)

As a user of UISpec4j with its Assertions that have a timeout, and some perilious test code when someone innocently mixed junit assertions with a UI test, I could relate to this really well.