После прочтения вопроса и некоторых комментариев кажется, что вам нужна методика для модульного тестирования асинхронных операций . doSomething () возвращается немедленно, но вы хотите, чтобы тестовый код ожидал его завершения, а затем провел несколько проверок.
Проблема в том, что тест не знает о потоках, порождаемых вызовом, поэтому, очевидно, у него нет средств для их ожидания. Можно придумать много сложных (и, возможно, ошибочных) способов решения этой проблемы, но, на мой взгляд, здесь есть проблема дизайна. Модульный тест должен имитировать клиента какого-либо API, и он не должен предполагать ничего о реализации; Следует только тестировать функциональность, как это отражено в API и его документации. Поэтому я бы избегал попыток обнаруживать и отслеживать потоки, созданные асинхронным вызовом. Вместо этого я бы улучшил API тестируемого класса, если это необходимо. Класс, к которому относится асинхронный вызов, должен обеспечивать некоторый механизм для обнаружения завершения. Я могу придумать 3 способа, но, вероятно, есть еще:
1) Разрешить регистрацию слушателя, который получает уведомление после завершения операции
2) Предоставление синхронной версии операции. Реализация может вызвать асинхронную версию, а затем заблокировать до завершения. Если класс не должен предоставлять такой метод, его видимость может быть уменьшена до защищенного пакета, чтобы тест мог получить к нему доступ.
3) Использование шаблона ожидания-оповещения для какого-либо видимого объекта.
Если класс не предоставляет такого механизма, то он не является действительно тестируемым, и, что еще хуже, его, вероятно, также нельзя использовать повторно.