Earlgrey is slow when accessing NavBar/TabBar Items
up vote
1
down vote
favorite
As EarlGrey runs in the process and there is no install/uninstall process involved as in XCUI test framework, I expected tests to run faster but I noticed it is almost the same speed as XCUI test framework. Any reasons?
It's very slow to get TabBar or NavBar items. How can I speed up the process?
I'm using this for TabBar elements to match
let tabButtonMatcher: GREYMatcher = grey_allOf([grey_accessibilityLabel("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: tabButtonMatcher).perform(grey_tap()).assert(grey_sufficientlyVisible())
Similar for NavBar buttons also
let navMatch: GREYMatcher = grey_allOf([grey_accessibilityID("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: navMatch).perform(grey_tap())
ios swift earlgrey
add a comment |
up vote
1
down vote
favorite
As EarlGrey runs in the process and there is no install/uninstall process involved as in XCUI test framework, I expected tests to run faster but I noticed it is almost the same speed as XCUI test framework. Any reasons?
It's very slow to get TabBar or NavBar items. How can I speed up the process?
I'm using this for TabBar elements to match
let tabButtonMatcher: GREYMatcher = grey_allOf([grey_accessibilityLabel("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: tabButtonMatcher).perform(grey_tap()).assert(grey_sufficientlyVisible())
Similar for NavBar buttons also
let navMatch: GREYMatcher = grey_allOf([grey_accessibilityID("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: navMatch).perform(grey_tap())
ios swift earlgrey
1
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
1
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
1
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
1
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
1
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
As EarlGrey runs in the process and there is no install/uninstall process involved as in XCUI test framework, I expected tests to run faster but I noticed it is almost the same speed as XCUI test framework. Any reasons?
It's very slow to get TabBar or NavBar items. How can I speed up the process?
I'm using this for TabBar elements to match
let tabButtonMatcher: GREYMatcher = grey_allOf([grey_accessibilityLabel("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: tabButtonMatcher).perform(grey_tap()).assert(grey_sufficientlyVisible())
Similar for NavBar buttons also
let navMatch: GREYMatcher = grey_allOf([grey_accessibilityID("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: navMatch).perform(grey_tap())
ios swift earlgrey
As EarlGrey runs in the process and there is no install/uninstall process involved as in XCUI test framework, I expected tests to run faster but I noticed it is almost the same speed as XCUI test framework. Any reasons?
It's very slow to get TabBar or NavBar items. How can I speed up the process?
I'm using this for TabBar elements to match
let tabButtonMatcher: GREYMatcher = grey_allOf([grey_accessibilityLabel("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: tabButtonMatcher).perform(grey_tap()).assert(grey_sufficientlyVisible())
Similar for NavBar buttons also
let navMatch: GREYMatcher = grey_allOf([grey_accessibilityID("Something"), grey_accessibilityTrait(UIAccessibilityTraitButton), grey_sufficientlyVisible()])
EarlGrey.selectElement(with: navMatch).perform(grey_tap())
ios swift earlgrey
ios swift earlgrey
edited Oct 16 at 18:56
asked Oct 16 at 2:52
user1165756
23039
23039
1
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
1
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
1
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
1
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
1
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18
add a comment |
1
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
1
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
1
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
1
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
1
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18
1
1
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
1
1
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
1
1
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
1
1
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
1
1
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
You must remove grey_sufficientlyVisible
from your matchers because it doesn't make sense. This matcher is guaranteed to work well in the assert
statement, but it seems it's inefficient to pass as a matcher parameter.
EarlGrey interacts with touch events on the run loop and, generally, it interacts with the application as well as a real user. Its unlikely tests will be fast in this case, especially compared with KIF which calls selectors on UI elements instead of passing touch events. That's not bad, it's an expected behavior for functional tests. By the way, you could speed up tests by disabling animations:
GREYTestHelper.enableFastAnimation()
Regarding your question related to matchers, I would suggest you try several approaches and find one which is suited in your case.
At first sight, it should be worth to just find a UITabBarItem
using grey_kindOfClass
.
Matcher example (not working)
grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])
But it's not the working solution.
Let's see on view hierarchy:
So if you rely on UITabBarItem
it doesn't work, because there is no such element. You can see, that there is a private UIKit class called UITabBarButton
which is not supposed to interact with. Moreover, it's not a subclass of UIButton
, but it's a subclass of UIControl
😀
Instead, I would recommend to select element on UITabBar
using inRoot
function.
Matcher example (working)
EarlGrey.selectElement(with: grey_text(tabbarTitle))
.inRoot(grey_kindOfClass(UITabBar.self))
.perform(grey_tap())
In this case, you find an element, which has the expected text and which is located on the UITabBar
.
For selection elements on the navigation bar it's possible to use variations of this matcher:
Matcher example to find the element on navigation bar
EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
.inRoot(grey_kindOfClass(UINavigationBar.self))
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
You must remove grey_sufficientlyVisible
from your matchers because it doesn't make sense. This matcher is guaranteed to work well in the assert
statement, but it seems it's inefficient to pass as a matcher parameter.
EarlGrey interacts with touch events on the run loop and, generally, it interacts with the application as well as a real user. Its unlikely tests will be fast in this case, especially compared with KIF which calls selectors on UI elements instead of passing touch events. That's not bad, it's an expected behavior for functional tests. By the way, you could speed up tests by disabling animations:
GREYTestHelper.enableFastAnimation()
Regarding your question related to matchers, I would suggest you try several approaches and find one which is suited in your case.
At first sight, it should be worth to just find a UITabBarItem
using grey_kindOfClass
.
Matcher example (not working)
grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])
But it's not the working solution.
Let's see on view hierarchy:
So if you rely on UITabBarItem
it doesn't work, because there is no such element. You can see, that there is a private UIKit class called UITabBarButton
which is not supposed to interact with. Moreover, it's not a subclass of UIButton
, but it's a subclass of UIControl
😀
Instead, I would recommend to select element on UITabBar
using inRoot
function.
Matcher example (working)
EarlGrey.selectElement(with: grey_text(tabbarTitle))
.inRoot(grey_kindOfClass(UITabBar.self))
.perform(grey_tap())
In this case, you find an element, which has the expected text and which is located on the UITabBar
.
For selection elements on the navigation bar it's possible to use variations of this matcher:
Matcher example to find the element on navigation bar
EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
.inRoot(grey_kindOfClass(UINavigationBar.self))
add a comment |
up vote
1
down vote
You must remove grey_sufficientlyVisible
from your matchers because it doesn't make sense. This matcher is guaranteed to work well in the assert
statement, but it seems it's inefficient to pass as a matcher parameter.
EarlGrey interacts with touch events on the run loop and, generally, it interacts with the application as well as a real user. Its unlikely tests will be fast in this case, especially compared with KIF which calls selectors on UI elements instead of passing touch events. That's not bad, it's an expected behavior for functional tests. By the way, you could speed up tests by disabling animations:
GREYTestHelper.enableFastAnimation()
Regarding your question related to matchers, I would suggest you try several approaches and find one which is suited in your case.
At first sight, it should be worth to just find a UITabBarItem
using grey_kindOfClass
.
Matcher example (not working)
grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])
But it's not the working solution.
Let's see on view hierarchy:
So if you rely on UITabBarItem
it doesn't work, because there is no such element. You can see, that there is a private UIKit class called UITabBarButton
which is not supposed to interact with. Moreover, it's not a subclass of UIButton
, but it's a subclass of UIControl
😀
Instead, I would recommend to select element on UITabBar
using inRoot
function.
Matcher example (working)
EarlGrey.selectElement(with: grey_text(tabbarTitle))
.inRoot(grey_kindOfClass(UITabBar.self))
.perform(grey_tap())
In this case, you find an element, which has the expected text and which is located on the UITabBar
.
For selection elements on the navigation bar it's possible to use variations of this matcher:
Matcher example to find the element on navigation bar
EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
.inRoot(grey_kindOfClass(UINavigationBar.self))
add a comment |
up vote
1
down vote
up vote
1
down vote
You must remove grey_sufficientlyVisible
from your matchers because it doesn't make sense. This matcher is guaranteed to work well in the assert
statement, but it seems it's inefficient to pass as a matcher parameter.
EarlGrey interacts with touch events on the run loop and, generally, it interacts with the application as well as a real user. Its unlikely tests will be fast in this case, especially compared with KIF which calls selectors on UI elements instead of passing touch events. That's not bad, it's an expected behavior for functional tests. By the way, you could speed up tests by disabling animations:
GREYTestHelper.enableFastAnimation()
Regarding your question related to matchers, I would suggest you try several approaches and find one which is suited in your case.
At first sight, it should be worth to just find a UITabBarItem
using grey_kindOfClass
.
Matcher example (not working)
grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])
But it's not the working solution.
Let's see on view hierarchy:
So if you rely on UITabBarItem
it doesn't work, because there is no such element. You can see, that there is a private UIKit class called UITabBarButton
which is not supposed to interact with. Moreover, it's not a subclass of UIButton
, but it's a subclass of UIControl
😀
Instead, I would recommend to select element on UITabBar
using inRoot
function.
Matcher example (working)
EarlGrey.selectElement(with: grey_text(tabbarTitle))
.inRoot(grey_kindOfClass(UITabBar.self))
.perform(grey_tap())
In this case, you find an element, which has the expected text and which is located on the UITabBar
.
For selection elements on the navigation bar it's possible to use variations of this matcher:
Matcher example to find the element on navigation bar
EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
.inRoot(grey_kindOfClass(UINavigationBar.self))
You must remove grey_sufficientlyVisible
from your matchers because it doesn't make sense. This matcher is guaranteed to work well in the assert
statement, but it seems it's inefficient to pass as a matcher parameter.
EarlGrey interacts with touch events on the run loop and, generally, it interacts with the application as well as a real user. Its unlikely tests will be fast in this case, especially compared with KIF which calls selectors on UI elements instead of passing touch events. That's not bad, it's an expected behavior for functional tests. By the way, you could speed up tests by disabling animations:
GREYTestHelper.enableFastAnimation()
Regarding your question related to matchers, I would suggest you try several approaches and find one which is suited in your case.
At first sight, it should be worth to just find a UITabBarItem
using grey_kindOfClass
.
Matcher example (not working)
grey_allOf([grey_kindOfClass(UITabBarItem.self), grey_text(title)])
But it's not the working solution.
Let's see on view hierarchy:
So if you rely on UITabBarItem
it doesn't work, because there is no such element. You can see, that there is a private UIKit class called UITabBarButton
which is not supposed to interact with. Moreover, it's not a subclass of UIButton
, but it's a subclass of UIControl
😀
Instead, I would recommend to select element on UITabBar
using inRoot
function.
Matcher example (working)
EarlGrey.selectElement(with: grey_text(tabbarTitle))
.inRoot(grey_kindOfClass(UITabBar.self))
.perform(grey_tap())
In this case, you find an element, which has the expected text and which is located on the UITabBar
.
For selection elements on the navigation bar it's possible to use variations of this matcher:
Matcher example to find the element on navigation bar
EarlGrey.selectElement(with: grey_kindOfClass(UIButton.self))
.inRoot(grey_kindOfClass(UINavigationBar.self))
edited Nov 18 at 9:23
answered Nov 18 at 8:19
Vladimir Kaltyrin
335112
335112
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52827294%2fearlgrey-is-slow-when-accessing-navbar-tabbar-items%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
What matcher are you using?
– gran_profaci
Oct 16 at 18:04
1
Edited the question with the matchers
– user1165756
Oct 16 at 18:57
1
Can you check with grey_sufficientlyVisible() removed from the matcher?
– gran_profaci
Oct 17 at 21:19
1
No difference. Is there any way to just go directly to UINavBar or TabBar items? Also it prints as in the hierarchy, but I can't use UITabBarButton or UITabBarItem with grey_isKindOf "<UITabBarButton:0x7fb37f741ee0; AX=Y; AX.label='Something'; AX.frame={{168.00000000596046, 814}, {77.999999988079054, 48}}; AX.activationPoint={207, 838}; AX.traits='UIAccessibilityTraitButton,UIAccessibilityTraitSelected'; AX.focused='N'; frame={{168.00000000596046, 1}, {77.999999988079068, 48}}; alpha=1>"
– user1165756
Oct 22 at 16:44
1
You can. I don't see any reason not to tbh.
– gran_profaci
Oct 22 at 23:18