How to Access My Swift Classes from My UI Tests

Is it possible to hide classes from ui tests

Assuming the following structure:

MyTestHelperClassName: XCTestCase {
    //... your helper methods
}

Remove its subclass declaration of XCTestCase
i.e the : XCTestCase part

Then it will not appear in the "Test Navigator"

Access to project code from XCTestCase - UI Test

Accessing your project's code via @testable import is only possible in UnitTests. When you are running UITests this is not working, because during a UITest your test class cannot access your app's code.

From Apple's Docs:

UI testing differs from unit testing in fundamental ways. Unit testing
enables you to work within your app's scope and allows you to exercise
functions and methods with full access to your app's variables and
state. UI testing exercises your app's UI in the same way that users
do without access to your app's internal methods, functions, and
variables. This enables your tests to see the app the same way a user
does, exposing UI problems that users encounter.

If you want to logout after a test you have to do it via your app's User Interface: If there is a logout button somewhere in your app, navigate there at the end of your test and let the test tap() it.

run all test classes in xcode ui test

To run all of your tests, you can use the following command in Terminal:

$ xcodebuild test

Alternatively, you can use Scan for a simpler interface.

To automate the running of your tests, you can create a shell script to run this command. If you want the shell script to run automatically, use Jenkins or similar continuous integration software to run the shell script at specified intervals.

You can set a job up to run your tests using xcodebuild or scan, and send an email when the job completes, or just when it fails. There's an excellent blog post on how to install Jenkins on OS X here: https://nickcharlton.net/posts/installing-jenkins-osx-yosemite.html and I've written a blog post with notes about some things that might catch you out with the configuration: http://qualitytesting.tumblr.com/post/142473883709/building-with-jenkins-and-xcode. The email feature is available by default so you just need to configure the email addresses you want to receive the notification when you configure your job.

To run all the tests inside Xcode, you can use cmd+U or go to the Test Navigator on the left-hand side and click the play button that appears when you hover over your test suite.

Test object state during UI testing (iOS)

You won't be able to access variables from your application's code during a UI test. Your app and the UI tests run in separate executables and don't have access to each others' internals at runtime.

To check the state of your text fields, you'll need to either read the state from the XCUIElement representing the text field (if the state you're interested in is visible in the UI) or write a unit test to check the state.

From Apple (via this answer):

UI tests execute differently from Unit tests - Unit tests run inside your application process so they can access your application code. UI tests execute in a separate process, outside your application, so they can simulate how the user interacts with the application. It’s not expected that you will be able to access your app class from a UI test.

How to access a variable o watch a change in SwiftUI UI testing?

You already know how to find things on the screen so you just need to identify “what, after hitting the login button with correct credentials proves to me I was logged in?”

A success message?
An entirely new screen? Is there a control that is unique to that screen?

Assert on one of those things you expect to exist using exists

An added note, there is no reason to assert the existence of your login fields after you’ve pulled the value from them; getting the value proves they’re there so the assertions are redundant.

How to access a SwiftUI view's property from a UI Test case class?

UI tests do not test internal state. They only test UI-visible behaviors. To write a UI test against this type, the imageName should result in some behavior, and you then test that the behavior is visible. In this case, you might make the imageName translate to an accessibility label, which would allow VoiceOver to read it (and incidentally also allow UI tests to access it).

The best way to make an app UI-testable is to first make it accessible. Try out your app with VoiceOver. If it works well there, then it will likely also work well for UI testing.

---

Related Topics