IMO, с точки зрения модульного тестирования, мы должны , а не сосредоточиться на тестировании того, какой поток запущен в данный момент.Цель написания тестовых примеров - убедиться, что отдельные единицы исходного кода работают должным образом, поэтому мы должны сосредоточиться на результатах индивидуально, а не заботиться о какой-либо другой функциональности зависимого уровня (сервиса);Вот почему в модульном тестировании существует понятие mocking !Если SUT (тестируемая система) использует сервис, который имеет дело с асинхронными задачами, вы должны поиздеваться над ним, опять же, мы индивидуально фокусируемся на тестировании конкретной единицы исходного кода.
В качестве примера из реальной жизни, если мы имеемконтроллер представления MyViewController, который зависит от сетевого уровня NetworkingManager, например:
class MyViewController: UIViewController {
let networkManager = NetworkManager()
func doSomething() {
networkManager.getWhatever { isSuccess in
// here is the side effect
}
}
}
class NetworkManager {
func getWhatever(callback: (Bool) -> Void) {
//...
}
}
Когда мы стремимся протестировать doSomething, нам не нужно заботиться о методе getWhatever, поэтому мысмоделируйте NetworkManager и предоставьте соответствующую реализацию для нашего теста;Не имеет значения, в каком потоке выполняется обратный вызов getWhatever, вместо этого здесь утверждается, что побочные эффекты doSomething возникают при получении успеха или неудачи из getWhatever, не обращая внимания на его реализацию.,
Однако, если необходимо протестировать асинхронную задачу, вы можете использовать expectations для этого, тем не менее, ее использование должно быть с целью наблюдения за отдельным асинхронным кодом беззависимости.
Я бы согласился с вами, что это скорее интеграционное тестирование.В таком случае вы можете использовать утверждение свойства Thread.isMainThread:
Возвращает логическое значение, которое указывает, является ли текущий поток основным потоком.