This is a stub for content that will appear in September. References TestRail – https://www.gurock.com/testrail TestsRail API - http://docs.gurock.com/testrail-api2/start XCTest documentation - https://developer.apple.com/documentation/xctest XCUITest User Interface Tests - https://developer.apple.com/documentation/xctest/user_interface_tests
This post introduces you to a way to add identifiers in code for rows in a table. It also shows a couple of the ways you can query for a particular row.
I prefer to use the debugger built into Xcode, lldb, when learning how to locate elements on the screen. I have the ability to display the elements tree for every screen in my app. From that I can see accessibility identifiers, labels, values for UI elements plus coordinates for each element. From this information, I … Continue reading Use the Debugger When Writing XCUITest Code
When writing any UI Test automation it is important to interact with elements on the screen only when they are ready to be interacted with. When navigating to a new screen, you are not guaranteed that all of the screen elements exist and are hittable the very second that test code is executed. This post … Continue reading Are Elements Ready for Use?
In XCUITest automation, I arrange test code in using a Screen Object model pattern. This is based on the web's Page Object model. First, there is a group of classes which model screens on an app. Second, a group of classes contain test case functions that rely on the screen classes for instances of screen … Continue reading XCUIElement – Discovery
When writing your XCUITest UI test, it is important to provide enough data when an assertion fails so that someone looking at a test run report can most easily see what failed and begin to figure out the "why".