Unfortunately, the meaning of the term "unit testing" seems to have been lost, or supplanted.

Unit testing should (did) mean testing a 'unit' of an application, and was only one of several forms of testing. It nows seems to have taken on a different meaning entirely, and to the detriment of everyone.

In a multi-threaded application (or multi-processed) application, unit testing should not require any concurrency. Each thread procedure should be tested (and testable) in isolation. That is the very definition of 'unit testing'.

Once unit tests have been past, then you move to the next level of testing, 'Integeration tests'. Where you bring those units together and test that they integrate. Integration testing inevitably does not (often cannot) fit with the OK/Not OK pattern of results required by these unit testing frameworks.

But, as is often the case with silver bullet development paradigms, the counting of OKs & NOKs has become more important than what they simplistically represent, and so you arrive at the situation where people attempt to force fit all their phases of testing into the unit testing mould.

The fundamental issues of integration testing (and systems testing if anyone still does it), especially in concurrent systems, are such that they cannot (and should not) be forced into simplistic, static Yes/No tests. They need to consider the effects of non-determinism upon the interactions between units of concurrency. And that invariably requires running the integrated units together over time and monitoring both the content and timing of their interactions.

Doing this well, or even at all, with a fixed sequence of static binary truth tests simply isn't possible. Attempting to force fit intgration testing into the unit testing mould for the sole purpose of the statistics produced is counter productive in the extreme.