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 behaviour)?

In the good old days, you had a type, you called it, and you checked either what it returned and/or what other things it called.

Nowadays, you call a method and the actual work gets scheduled to run on the next available thread; you don’t know when it’ll actually start and call the other things – and what’s more, those other things could be concurrent too.

How do you deal with this? Do you abstract/inject the concurrent scheduler (e.g. abstract the Task Parallel Library and provide a fake/mock in the unit tests)?

What resources have you come across that helped you?

---

Edit

I’ve edited the question to emphasise testing the normal behaviour of the type (ignoring whatever parallel mechanism is used to take advantage of multi-core, e.g. the TPL)

---

Answer 1

The field of Unit testing for race conditions and deadlocks is relativly new and lacks good tools.

I know of two such tools both in early alpha/beta stages:

• Microsoft’s Chess
• Typemock Racer

ANother option is to try and write a “stress test” that would cause deadlocks/race condtions to surface, create multiople instances/threads and run them side by side. The downside of this approch is that if the test fail it would be very hard to reproduce it. I suggest using logs both in the test and production code so that you’ll be able to understand what happened.