Ovanes Markarian
All in all it sound as a huge amount of work ;)
1. Frankly I thought more in terms of running test cases in multiple processes. Either on a local host or in a cloud. Running in multiple threads have some small advantages (like no need to serialize extras test case data and some existing infrastructure), but IMO it breaks most important restriction of unit testing - all test units needs to be run independently (unless your classes are specially prepared for running in MT environment). Running in multi-process scenario is much more close to running test cases serially. In addition we do not need to worry about syncing access Boost.Test internals. 2. Managing dependency should not be a problem IMO. Boost.Test has rather simple model and running test units in parallel should not complicate it much. 3. I do not see, why we need to parallelize on test suites level. IMO it should be on test case level. 4. I do not see a problem with dependence on either Boost.Thread or Intel TBB (or anything else for that matter). In my design the logic of distribution resides in standalone runner application and we can have number of different runners with different dependencies. There is only some generic "distribution support logic which will reside in main library. And it does indeed non trivial piece of work. So if there are any volunteers... I'll be happy to help with general design and some core infrastructure changes Gennadiy