Тесты пользовательского интерфейса не должны ссылаться на код приложения, они предназначены для имитации постукивания пользователя внутри вашего приложения. Если бы во время этих тестов вы запрыгнули в код приложения, вы бы больше не тестировали то, что делает ваше приложение в реальном мире, вы бы тестировали то, что оно делает, когда им манипулировали так, как никогда не мог сделать пользователь. Тесты пользовательского интерфейса не должны нуждаться в каком-либо коде приложения больше, чем пользователь.
Конечно, для модульных тестов и интеграционных тестов вы используете @testable import …, чтобы получить доступ к любым методам и свойствам, которые не отмечены private или fileprivate. Все, помеченное private или fileprivate все равно будет недоступно из тестового кода, но все остальное, включая internal, будет доступно. Это тесты, в которых вы должны преднамеренно добавлять данные, которые не могут произойти в реальном мире, чтобы убедиться, что ваш код может их обработать. Эти тесты все равно не должны доходить до метода и вносить какие-либо изменения, иначе тест не будет на самом деле тестировать поведение кода.
Вы можете создать столько целей модульных тестов, сколько захотите в проекте, и вы можете используйте одну или несколько из этих целей для проведения интеграционных тестов, а не модульных тестов. Затем вы можете указать, какие цели запускаются в разное время, чтобы ваши более медленные интеграционные тесты не запускались каждый раз, когда вы тестировали и замедляли работу.
В модуле среды и в интеграционных тестах действительно есть все. Вы можете создать экземпляр контроллера представления и вызвать loadViewIfNeeded(), чтобы получить полную настройку представления. Затем вы можете проверить наличие различных торговых точек и запустить их для отправки действий (см. Метод UIControl sendActions(for: )). При условии, что вы настроили необходимые макеты, это позволит вам убедиться, что когда пользователь нажимает кнопку A, вызов отправляется на правильный метод вещи B.
Для тестов пользовательского интерфейса вам не нужно загрязнять ваше приложение. слишком много кода Вы можете использовать один аргумент командной строки, чтобы указать, что выполняются тесты пользовательского интерфейса, и использовать его для загрузки некоторых тестовых данных, входа в систему тестового пользователя или выбора конечной точки тестирования для сетевых вызовов. При хорошей архитектуре вам нужно будет выполнить настройку только один раз, когда приложение запускается, а остальной код не замечает, что оно использует тестовые данные (очень похоже на то, что у вас есть среда разработки и производственная среда, между которыми вы переключаетесь для сетевых вызовов). ).
Если вы хотите узнать больше о тестировании, у Свифта Пола Хадсона есть очень хорошая книга, которую вы можете проверить https://www.hackingwithswift.com/store/testing-swift. Он содержит множество примеров различных видов тестов и полезные советы о том, как их разбить.
Обновление на основе ваших правок и комментариев: Похоже, что вы действительно хотите, это интеграция тесты. Их легко не заметить в мире XCode, поскольку у них нет своей цели для создания. Они используют цель Unit Test, но тестируют несколько вещей, работающих вместе.
При условии, что вы не добавили private или fileprivate ни в одну из своих торговых точек, вы можете создавать тесты в цели Unit Test, которая обеспечивает розетки существуют, а затем вводят текст или запускают свои действия по мере необходимости для имитации навигации пользователя по вашему приложению.
Обычно этот вид тестирования будет просто go от одного контроллера представления ко второму, чтобы проверить, что правильный контроллер представления создается, когда происходит действие, но ничто не говорит, что он не может go дальше.
Вы не получите изображения экрана для неудачного теста, как вы делаете с тестами пользовательского интерфейса, и если вы используете раскадровки, обязательно создайте экземпляры ваших контроллеров представления из раскадровки. Убедитесь, что вы захватываете любые контроллеры навигации и тому подобное, что требуется.
Эта методология позволит вам вести себя так, как будто вы перемещаетесь по приложению, и при этом можете манипулировать любыми данными, которые вам нужны, когда они поступают в различные приложения. методы.
Если у вас есть метод с 10 строками в нем, и вы хотите настроить данные между строками 7 и 8, вам понадобится внешний вызов чего-то поддельного и внести в него изменения или использовать точку останова с командой отладчика, которая вносит изменения. Этот трюк с точкой останова очень полезен для отладки, но я не думаю, что использовал бы его для тестов, поскольку удаление точки останова сломало бы тест.