How do I test whether a view is hidden using XCUITest? A view is sometimes hidden (set in Xcode like this: Hidden view)
How do I test for that in XCUITest using Swift? In my case, the view is just a label. I tried something like this: XCTAssertFalse(app.staticTexts["pushNotificationInstruction"].accessibilityElementsHidden) . But that's not it. accessibilityElementsHidden is not the same as the view is hidden. Thanks.
Unfortunately, this is not currently possible using XCUITest. Here is a developer forum thread where an Apple engineer suggested filing a radar for this exact issue:
https://forums.developer.apple.com/message/46271
I have personally filed a couple radars relating to the limitations imposed by not being able to access certain properties of UIViews from within an XCUITest. I encourage you to do the same and provide details of the scenarios you are blocked from testing because of this deficiency in XCUITest.
You can assert that the view does not exists and use another test to check the scenario when it does exists. Maybe a bit fragile, but that would cover you case.
let viewControllerShown = app.otherElements["view_myviewcontroller"].waitForExistence(timeout: 5)
XCTAssert(viewControllerShown)
let instructionViewExists = app.staticTexts["pushNotificationInstruction"].exists
XCTAssertFalse(instructionViewExists)
An expedient solution is to carry the visibility state of the view in its accessibilityidentifier.
In your view controller:
view.isHidden = hideView
view.accessibilityidentifier = "view1"+(hideView ? "hidden" : "")
In your tests:
XCTAssert(app.otherElements["view1"].exists)
or
XCTAssertFalse(app.otherElements["view1"].exists)
Looking at the documentation of exist:
The fact that an element exists does not imply that it is hittable.
Elements can exist offscreen, or exist onscreen but be hidden by
another element, causing their isHittable property to return false.
It means that you can check:
if uiElement.exists && uiElement.isHittable {
XCTFail()
}
Related
I've got a subclass of UIView, let's say it's class DemoView: UIView { } which contains UILabel and UIButton. I needed to group it and add UIAccessibilityCustomAction so I've overriden the var accessibilityElements: [Any]? and used union to connect both elements. I've also assigned "Users" string to accessibilityLabel.
From user perspective this works as it should, VoiceOver reads Users and then user can select custom action which is named Edit.
Problem is that I don't know how can I fire this custom action from UITests. I know that XCUIElement contains array of UICustomActions and I can get its selector but then what?
I talked to Apple Engineers during WWDC19 Accessibility and Testing Labs and they said it is not possible right now. The reason why accessibility is not available during testing are security concerns. What they also said is that they don't use UITests for testing UIAccessibility and when creating accessibility elements support two cases - when there are UITests running and not.
I recommend making a suggestion using Feedback Assistant.
The purpose you're tring to reach isn't possible currently with iOS13 and Xcode 11.
The UITesting framework doesn't access the application code as unit tests do: you can't get an instance to perform selector + the array of custom actions is nil when in UITest ⇒ every custom action isn't reachable and then can't be fired at all.
XCUITEST works thanks to the accessibility properties like accessibilityIdentifier but isn't definitely designed to simply work for VoiceOver (inconceivable and incomprehensible in my view).
I hope that something new with UI testing will be introduced during the next WWDC for REAL accessibility testing.
For anyone else stuck on this, if you have a direct reference to the UIView in question, I've (well, a coworker of mine) found the following 'hack' to work quite well.
let view: UIView = YourViewWithCustomAction()
let customActionName: String = "<Your custom action name here>"
let action: UIAccessibilityCustomAction = view.accessibilityCustomActions!.first(where: { $0.name == customActionName })!
_ = action.target!.perform(action.selector, with: action)
As a disclaimer, this might only work when you have a custom UIView subclass that implements its own override var accessibilityElements.
I am using iOS UITest for a Swift application. I use something like,
func testAllScreenNavigation() {
let app = XCUIApplication()
app.tabBars.buttons["Home"].tap()
app.navigationBars["Home"].buttons["More"].tap()
app.sheets.buttons["Cancel"].tap()
}
etc. to navigate some of the specific, tabs, buttons, etc. and switch to respective screens. But i want to navigate each and every screens of my Application (It can be BFS style navigation or DFS style navigation, no matter). Is there any way iOS provides so i can get all navigable elements and then explore deeper and deeper automatically for my App?
I also need to keep trace of which xcuoelement in a screen is already processed and which are not yet processed.
The only way I can think of is using Xcode UI test recorder feature.
While you are recording, navigate through all of your screens via the device/simulator and then the XCUIApplication() variable would be recorded with the appropriate references.
If the button/nav bar/any element has text on it, it will show up in the recorded code or else it will be referenced numerically.
Hope that helps.
Kind regards,
Mukund
I like your idea for getting all views and check whether the layouting and localization for example is fine.
I think you need to specify your criteria for "screens" and how they are accessed.
Basically, one could thing of the following structure
- UITabBarController
-- UISplitViewController
--- UINavigationController
---- UIViewController
----- UIBarButtonItems
----- UIView
----- UIButton
----- UISwitch
----- UITableViewCell
You could now go top down from the UITabBarController to the next controlling instance (might also skip one, e.g. SplitViewControllers on iPhones).
You can use the general property:
XCUIApplication().tabBars
Nevertheless that transition is the problem: How would you get from one ViewController to another and are they all position in the ViewController's View or do you have to loop the subviews of a view.
UIButton -> Touch Up Inside
UISwitch -> Value Changed
UITableViewCell -> DidSelectRowAtIndexPath
UIView -> UILongPressGestureRecognizer
This is how I would basically set it up:
For each UIViewController instance, get the related View (and perform the following call recursively).
Check all the subviews of a view.
For UIViews, go even further and check their subviews
For UIButtons, perform TouchUpInside
and so on.
Make sure to have a condition to stop going deeper, as UITableViews got a lot of subviews or your UIWebViews would of course be set up in a different way.
This way you should be able to navigate through a lot Views in your app hierarchy, but you will need some extensions for UIBarButtonItems, custom Gesture Recognizers and of course also for your "special" controls that might listen to value changes and perform a layout-change.
Accessing specific elements
In addition to the above approach where you simply get an array of elements of a specific type, you can access specific elements (e.g. those where you know they are of a very specific type with certain ValueChangeListeners or something)
To access a specific object in particular, like the TabBar example from above, you can use the accessibilityLabel like so. At first you need to declare the accessibilityLabel in your code or in the .xib-file/.storyboard:
// just to illustrate, so you get an idea:
self.tabBarController.isAccessibilityElement = true
self.tabBarController.accessibilityLabel = "tabBar"
And then do:
let tabBar = XCUIApplication().tabBars["tabBar"]
Here is Apple's documentation for setting these accessibilityLabels:
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html
A great way to get the related identifier of an element would be to use the Accessibility Inspector from Apple:
https://developer.apple.com/library/content/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityiniOSSimulatorwithAccessibilityInspector/TestAccessibilityiniOSSimulatorwithAccessibilityInspector.html
Accessing elements in general
To access elements in general, you need to make use of the XCUIElementType of these objects, here you will access the objects based on their classes.
E.g. you could call:
"tabBars", "navBars", "tables", "buttons", and so on from the elements in general.
Still you would be facing the issue with "special controls". As the Apple documentation lacks (imho) some detail about properties and attributes, I do recommend the docs here: https://blog.metova.com/guide-xcode-ui-test/ It provides a great overview of what is accessible and may help you getting some better understanding.
An overview of the available XCUIElementTypes can be found here. Basically, the elementType property is an enumerated value that represents the type of an element. XCUIElementType is a very large enumeration and some of its members do not apply to iOS applications (they apply to MacOS X apps). Some of the more commonly used values are:
Alert
Button
NavigationBar
TabBar
ToolBar
ActivityIndicator
SegmentedControl
Picker
Image
StaticText
TextField
DatePicker
TextView
WebView
https://developer.apple.com/reference/xctest/xcuielementtype?language=objc
I am trying to add iOS accessibility support/Voice Over to my app. My main screen has three main controls, but the third control is hosted within an embedded view controller.
I am setting accessibility elements in prepareForSegue and have confirmed that the embedded view controller controls are all loaded. Problem is I can still only select the first two controls which are in the enclosing view controller.
self.view.accessibilityElements =
#[
self.cmdMenu, // works
self.collectionView, // works
self.childViewController.peerMenu // doesn't work
];
All three views have isAccessibilityElement = YES.
Am I missing something? I can't imagine that there is a restriction on the accessibility elements being in the same view controller.
I found my bug and now have Voice Over working. In the process I figured out a number of things that I would like to share.
To my original question, you can reference controls in your child view controllers from your main view controller. You can add the controls directly (as I did in my question) or you can add all accessibility elements in the child view controller using self.view.accessibilityElements = #[ _control1, childViewController.view, childViewController2.view].
If you add all of the controls in your child view controller as in (1.) then ensure that childViewController.view.isAccessibilityElement = NO.
You can add any kind of object to accessibilityElements, even elements that have no accessibility information. The API will not assert or warn you. This ended up being my bug.
If your UI changes and you need to change the number or order of items in your accessibilityElements array tell UIKit about it using UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, self). The notification argument (where I'm sending self) tells Voice Over where it should position its cursor when the notification completes.
If you want to read aloud some text for a transient notification (imagine when Clash Of Clans tells you how many Gems you found in that Tree Stump) call UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, messageText). One caveat, this won't read aloud the messageText unless there is no other Voice Over in progress. You need to manage the timing yourself. Submitted a bug on this. Apple could make this a lot better.
If you are using UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, messageText) you can listen for UIAccessibilityAnnouncementDidFinishNotification, but unfortunately this notification has almost no value. You only will get notified if your messageText was fully spoken. It doesn't tell you that it was spoken, but interrupted, and it will also not get triggered for any text spoken through the UIKit framework.
The Accessibility Inspector in the iOS Simulator kind of sucks. If your accessibility settings are correct, it can tell you what is there. If you have a problem the Inspector does not provide you any information about what is wrong. This is true of the entire UIAccessibility API. It is so easy to use that it almost always works. But when it doesn't work you need to resort to hunt and peck to figure it out. The API needs some assertions or console messages similar to how Apple handles Constraint warnings. Spoiler alert: the Accessibility Inspector in Xcode 8 is wayyyyy better, but still would not have helped with my issue.
There is a ton of good information in the UIAccessibility.h header. If you are embarking on UIAccessibility support, it is a good read.
The question is actually really simple:
Is there a way to assert the displayed value from a specific label (e.g. UILabel) when using an accessibility label on this object?
As far as I see it, all the assertions (e.g. XCTAssertEquals) made in the examples, be it from a WWDC Talk or Blogposts, are only checking if an element exists for a query like XCTAssertEquals(app.staticTexts["myValue"].exists, true) or if the number of cells in a table is correct XCTAssertEquals(app.tables.cells.count, 5). So, when avoiding accessibility labels it's possible to check if an object has a certain value displayed, but not which object / element.
And when using accessibility labels, it robs me of the opportunity to query against the displayed values, because app.staticTexts["myValue"] will now fail to deliver a result but app.staticTexts["myAccessibilityLabel"] will hit.
Assuming I want to test my "Add new Cell to Table" functionality, I can test that there is really a new cell added to the list, but I have no idea if the new cell is added at the top or the bottom of the list or somewhere in between.
For me, an easy way to check if a specific element has a certain value should be a no-brainer when it comes to UI Testing.
It is possible that due to the missing documentation I might overlook the obvious. If so, just tell me.
Be sure to set the .accessibilityValue property of the UILabel whenever you set its .text value. Then in UITest, you can test the accessibility value like this:
let labelElement = app.staticTexts["myLabel"]
...
XCTAssertEqual(labelElement.value as! String, "the expected text")
I think you are asking a few different things, so I will try to answer each question individually.
Is there a way to assert the displayed value from a specific label (e.g. UILabel) when using an accessibility label on this object?
In short, no. UI Testing works by hooking into accessibility APIs, so you are limited to querying for objects based on that. You can, however, check the -value property of certain elements, such as controls. This is used to test if a switch is on or off. Note that these boil to down using accessibility APIs as well, just a different method (-accessibilityValue over -accessibilityIdentifier and -accessibilityLabel).
...but I have no idea if the new cell is added at the top or the bottom of the list or somewhere in between.
To interrogate an XCUIElement for its frame you can use the new XCUIElementAttributes protocol which exposes -frame. For example:
let app = XCUIApplication()
app.launch()
app.buttons["Add New Cell to Table"].tap()
let lastCell = app.cells["Last Cell"]
let newCell = app.cells["New Cell"]
XCTAssert(newCell.exists)
XCTAssert(newCell.frame.minY > lastCell.frame.maxY)
For me, an easy way to check if a specific element has a certain value should be a no-brainer when it comes to UI Testing.
If you think of everything in terms of accessibility this becomes a non-issue. UI Testing can only interact with your elements via accessibility APIs, so you must implement them. You also get the added benefit of making your app more accessible to user's with those settings enabled.
Try setting both the -accessibilityLabel or -accessibilityIdentifier for the cell to the displayed text. UI Testing can be finicky as to which one it uses.
It is possible that due to the missing documentation I might overlook the obvious. If so, just tell me.
XCTest and UI Testing don't have any official documentation. So I've gone and extracted my own from the header files exposed in the framework. Note than even though they were pulled from source, they are unofficial.
XCTest / UI Testing Documentation
What works for me is to set the accessibility identifier of the UILabel to let's say MyLabel.
func myLabelText() -> String {
let myLabelUIElement: XCUIElement = self.application.staticTexts["MyLabel"]
return myLabelUIElement.label
}
Tested with Xcode 8 and iOS 10
From the apple forums it looks like it is possible to get the value of the label:
The only way I've found is to not set an Accessibility Label, but use identifier instead. Then XCUIElement.label will change to match the current text of the label.
However there is a gotcha: if you have previously set Accessibility Label in XC, and remove it, an entry setting the label to "" remains in the storyboard. In this case, not only will calling .label will return "", but you won't be able to query for the label by it's text!
The only thing you can do is delete and re-add the label, or manually edit the xml.
lastobelus - https://forums.developer.apple.com/thread/10428
The solution in this question* uses setHidden to hide and unhide a WKInterfaceGroup:
atypeofGroup.setHidden(true)
atypeofGroup.setHidden(false)
But the problem is, the group will appear and disappear abruptly, it doesn't look professional. Can someone guide me please? Not sure whether it is related to this:
atypeofGroup.animationDidStart(anim: CAAnimation!)
*hide and show WKInterfaceGroup programmatically
This is a great question, but it just isn't possible to animate a change between two groups with the current implementation of WatchKit. I definitely wish it was as well.
The only options you have are to switch interface controllers entirely through the reloadRootControllersWithNames:contexts: or to show/hide a couple of groups using the approach you listed first. Here's a small example of how you could switch from a SimpleInterfaceController to a FirstInterfaceController and SecondInterfaceController in a page set.
class SimpleInterfaceController : WKInterfaceController {
override func willActivate() {
super.willActivate()
let names = ["FirstInterfaceIdentifier", "SecondInterfaceIdentifier"]
WKInterfaceController.reloadRootControllersWithNames(names, contexts: nil)
}
}
I am not sure where you found the following code snippet, but it is certainly not part of the public APIs on WKInterfaceGroup.
atypeofGroup.animationDidStart(anim: CAAnimation!)
While I understand none of these answers are ideal, they are all we have access to at the moment. If you have the time, I'd suggest filing a feature request on Apple's bug reporting system.