Подводные камни тестирования кода в Swift Concurrency

[Grigorii_K]

Появление протоколов Executor/SerialExecutor было одним из этапов развития идеи назначения кастомных исполнителей акторам в будущем, что в некотором виде уже реализовано в Swift 5.9

Не увидел в примерах использование XCTestExpectation, который вроде как раз предназначен для тестирования асинхронного кода. Не пробовали?

[IBS_habrablog]

Спасибо за коммент, да вы правы, что идея данного протокола - изменить или расширить функционал асинхронного программирования, в частности тестирования такого кода. Пока Swift 5.9 все же находится на стадии бета версии, поэтому мы постарались показать, как это можно использовать в будущих версиях языка в рамках текущей. Насчет XCTestExpectation, мы используем его в одном из наших тестов, и честно говоря, он не отличается большой производительностью и высоким прохождением. Да, вариант неплохой, но все равно не гарантирует успешное прохождение тестов в большинстве случаев.

[Grigorii_K]

Невольно закрадывается мысль, что было бы достаточно просто отключить параллельное выполнение тестов.

[IBS_habrablog]

Параллельность отключать - не очень идея. Во-первых, это не решает проблему, к сожалению, а во-вторых, можно словить ошибку Xcode: An unknown error occurred when referencing the test plan, и тогда все отвалится))

[ws233]

А не проще ли было просто использовать Set вместо массива и сравнивать Set?

[IBS_habrablog]

А что если нам важен порядок, который Set не может предоставить? Мы упоминали об этом в статье.

[NineNineOne]

Я правильно понял, что в статье показали как "поправить тесты", чтобы они всегда проходили успешно?

Если да, то объясните пожалуйста, как это связано с поведением самого приложения.

Как я понял, настройка хука позволяет успешно провести именно тесты, а в самом приложении такого кода нет, и вряд ли вы будете на главной выполнять такое количество работы, но возможно я в чем-то ошибаюсь или чего-то не понял в статье.

Заранее благодарю за ответы

[IBS_habrablog]

Можно написать собственный сервис, где переопределить глобальный хук, и сделать это через синглтон, например, ибо вряд ли у вас будет еще подобный сервис в приложении. И уже оттуда дергать методы для тестов. А насчет "такого количество работы", здесь примеры были для наглядности, чтобы показать как будут вести себя тесты при количестве их исполнения больше 1)) А ничто так не показывает реальную статистику, как большие цифры). Кстати, у Apple есть подобный механизм под капотом, но он работает через раз https://github.com/apple/swift/issues/63104
P. S. Не говорю, что синглтон - панацея, ибо ухудшает тестирование в теории, можно обойтись и без него. Мы хотели донести идею написания собственного сервиса.

[yu_vl]

Возможно так было бы проще :)

@MainActor
func testAsyncBasic() async {...}

Ну, или так, например

Task { @MainActor in
 ...
}

[IBS_habrablog]

В целом если указать @MainActor внутри таски, а не помечать целиком весь метод как @MainActor, то работает плюс минус неплохо, однако тем не менее производительность у хука выше.