Unit testing concurrent software - what do you do?

Question

As software gets more and more concurrent, how do you handle testing the core behaviour of the type with your unit tests (not the parallel behaviour, just the core

Answer 1

I recommend picking up a copy of Growing Object Oriented Software by Freeman and Pryce. The last couple of chapters are very enlightening and deal with this specific topic. It also introduces some terminology which helps in pinning down the notation for discussion.

To summarize .... Their core idea is to split the functionality and concurrent/synchronization aspects.

• First test-drive the functional part in a single synchronous thread like a normal object.
• Once you have the functional part pinned down. You can move on to the concurrent aspect. To do that, you'd have to think and come up with "observable invariants w.r.t. concurrency" for your object, e.g. the count should be equal to the times the method is called. Once you have identified the invariants, you can write stress tests that run multiple threads et.all to try and break your invariants. The stress tests assert your invariants.
• Finally as an added defence, run tools or static analysis to find bugs.

For passive objects, i.e. code that'd be called from clients on different threads: your test needs to mimic clients by starting its own threads. You would then need to choose between a notification-listening or sampling/polling approach to synchronize your tests with the SUT.

• You could either block till you receive an expected notification
• Poll certain observable side-effects with a reasonable timeout.