The point of noury is what is the way to approach concurrency when doing TDD. Now how to build reliable ….
I won’t pretend to answer such a broad question with anything definitive, but I’d start my investigation of concurrency with a look at databases. One of the primary features of any multi-user database (not just GemStone!) is that transactions are in practice concurrent but the system is designed to apply them as if they were serial and in a way where order does not matter. So I would attempt to identify the concurrent tasks and verify that they each got the result that they would have obtained had they been applied in various serial fashions.
Imagine that DrTDD should be extended to support concurrent programming. Then this is the question that we want to get answer.
I would look for a way to pass a set of repeatable tasks to DrTDD and let the testing framework run them in various orders then run them concurrently with interrupts and switching contexts. James