After reading the question and some comments, it seems that what you need is a technique for unit testing asynchronous operations. doSomething() returns immediately, but you want the test code to wait for its completion, and then do some validations.
The problem is that the test is not aware of the threads being spawned by the call, so apparently it has no means of waiting for them. One can think of many sophisticated (and probably flawed) ways to solve this, but in my opinion there is a design problem here. A unit test should simulate a client of some API, and it should not assume anything about the implementation; It should only test functionality, as reflected by the API and its documentation. Therefore, I would avoid trying to detect and track the threads created by the async call. Instead, I would improve the API of the tested class, if needed. The class where the async call belongs to should provide some mechanism for detecting termination. I can think of 3 ways, but there are probably more:
Allow registering a listener that gets notified once the operation is completed
Providing a synchronous version of the operation. The implementation can call the async version, and then block until completion. If the class should not be exposing such a method, its visibility can be reduced to package protected, so that the test can access it.
Using the wait-notify pattern, on some visible object.
If the class provides no such mechanism, then it is not really testable, and worse, it is probably not very reusable either.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…