Nat Pryce (Independent Consultant)

Experience Report & Tutorial

60 minutes

You Will Need: To be a programmer with some experience of TDD and asynchronous systems

Popular frameworks for test-driven development assume that the test and the code under test execute synchronously. The test invokes the code under test and control does not return to the test until that code has finished executing. This works well for unit testing. However, the assumption does not often hold when testing at a larger scale: integration testing, system testing, enterprise integration testing. At those scales, tests must cope with asynchrony, concurrency, and event driven architectures. Because this is so difficult, and there is so little support from existing tools, many teams start by doing just unit testing. They then hit integration problems late in the process.

Teams that do address end-to-end testing often hit difficulties:

* "Flickering" tests that fail only occasionally

* False positives, caused by race conditions that make the test and the system get out of sync.

* Poor test performance that slows down the TDD feedback cycle.

* Messy test code, with ad-hoc sleeps and timeouts scattered liberally throughout the tests.

This presentation/experience report/tutorial will explain how to avoid these problems so teams can take full advantage of the TDD process at all scales of system development and deployment.

Starting as an experience report, the presentation describes three systems that were built using a TDD process, and how we tested them:

* An enterprise-integration application that communicates with reliable message queues and pub/sub, and has a GUI client that runs on the desktop.

* A system that uses a content-based pub/sub event-bus to publish and compose services in a service-oriented architecture.

* A financial analysis application that has a compute grid and REST web services at the back-end and an AJAX web front-end written with GWT.

While at first glance the three systems are quite different and use a variety of architectures and technologies, the tests for these three systems cope with asynchrony and concurrency in similar ways. This similarity can be seen as an abstract architectural style that can be applied to testing any system that has concurrent or asynchronous behaviour.

The presentation then segues into a tutorial that explains this architectural style, and how that architectural style and some simple testing idioms can avoid the difficulties listed above.

About The Presenter: