chore(e2e): maintenance for automated tests after iOS 26.2 #3430
Conversation
KrzysztofWojnar
requested review from
kkafar,
kligarski,
kmichalikk and
t0maboro
and removed request for
kkafar and
t0maboro
KrzysztofWojnar
force-pushed
the
@KrzysztofWojnar/e2e-test-maintenance-ios-26.2
branch
from
a48c2f0 to
e82c68e
Compare
KrzysztofWojnar
changed the title
KrzysztofWojnar
changed the title
KrzysztofWojnar
force-pushed
the
@KrzysztofWojnar/e2e-test-maintenance-ios-26.2
branch
from
d48d998 to
2401b65
Compare
| (await backButtonElement.getAttributes()) as unknown as { | ||
| elements: { className: string }[]; | ||
| }; |
There was a problem hiding this comment.
await backButtonElement.getAttributes() returns Detox.IosElementAttributes | Detox.AndroidElementAttributes | { elements: Detox.IosElementAttributes[]; } | { elements: Detox.AndroidElementAttributes[]; }, maybe we can handle this type somehow instead of forcing a type.
There was a problem hiding this comment.
That's the tough one.
It is an iOS-version-specific, behavior-based implementation for a technical selector, BUT QUITE READABLE (comparing to my other options). The biggest problem with the 'className' field is that it is not documented (I'm using the Hyrum's law).
It may break in future versions, but I can't predict it and finding this header back button in another way (filtering by other properties) is equally uncertain (or may break even easier). I don't have more robust solutions, you can call it a skill issue.
This probably won't make you feel any better, but I don't like it either.
There was a problem hiding this comment.
Oh, I can use magic numbers alternatively (backButtonElement.atIndex(0)).
I bet most people would do this in this case.
There was a problem hiding this comment.
Ok, I see what you mean. I think the current version is all right then.
| const iosVersion = semverCoerce(getIOSVersion().replace('iOS', ''))!; | ||
| if (semverSatisfies(iosVersion, '>=26.0')) { |
There was a problem hiding this comment.
I'm wondering if we need semver for this? On the other hand, it's just the example app so I guess that it's okay.
There was a problem hiding this comment.
I wanted to save some time and several lines of code by adding the dev dependency, but I agree - it is an overkill and we can parse MAJOR.MINOR (or just bare MAJOR) oursevles. I don't have a strong opinion about it.
There was a problem hiding this comment.
No, we don't need external dependency for this. Simple helper function is enough for that. Given what is going on with NPM & supply chain attacks recently -> lets avoid any unnecessary dependencies.
`} catch {` and `} catch (_) {` it's pretty the same, "(_)" shows we intentionally skip the error handling, but skipping it is just more concise
Co-authored-by: Krzysztof Ligarski <[email protected]>
kkafar
left a comment
kkafar
left a comment
There was a problem hiding this comment.
Hey! Thanks for the PR. I've left few questions & remarks. Please answer them (or let us know that the PR needs an assignee).
| describe('Bottom tabs and native stack', () => { | ||
| beforeEach(async () => { | ||
| await device.reloadReactNative(); | ||
| await device.launchApp({ newInstance: true }); |
There was a problem hiding this comment.
I have a question here. Why do we relaunch application instead of reloading RN? This was done mostly to save CI time IIRC, so it is a subject to be changed, but I need reasoning here.
| beforeEach(async () => { | ||
| await device.reloadReactNative(); | ||
| // await device.launchApp({ newInstance: true }); | ||
| await device.launchApp({ newInstance: true }); |
There was a problem hiding this comment.
Same here, and in every other place, where it has been done.
| const iosVersion = semverCoerce(getIOSVersion().replace('iOS', ''))!; | ||
| if (semverSatisfies(iosVersion, '>=26.0')) { |
There was a problem hiding this comment.
No, we don't need external dependency for this. Simple helper function is enough for that. Given what is going on with NPM & supply chain attacks recently -> lets avoid any unnecessary dependencies.
There was a problem hiding this comment.
I wonder about naming here. What are component-objects? Shouldn't be this kind of util directory with locators.js / actions.js?
| } | ||
| async function getIOSBackButton() { | ||
| const iosVersion = semverCoerce(getIOSVersion().replace('iOS', ''))!; | ||
| if (semverSatisfies(iosVersion, '>=26.0')) { |
There was a problem hiding this comment.
Does this function work only on iOS 26+?
| await element(by.id('home-button-open-second')).tap(); | ||
|
|
||
| await element(by.id('BackButton')).tap(); | ||
| await tapBarBackButton(); |
There was a problem hiding this comment.
This is an iOS only test. We have nice & clean way to detect a back button & tap it & we replace it with the complicated logic in component-objects/back-button.ts? Why do we do this? My guess would be that this version does not work, but I need confirmation & explanation.
Description
Closes https://github.com/software-mansion/react-native-screens-labs/issues/540
Broad changes after iOS 26.2 and some by-the-way fixes or improvements.
Not fixed tests:
iOS tests for example Test2809 should be aligned later with an output of PR #3303.
iOS tests for examples Test645 and Test649 are affected by issue #566
Changes
Detox e2e tests. Increased test isolation. Bar back button technical selector depends now on ios version.
Some android emulators my get a pop-up about using stylus which interrupts the test flow – it is disabled in the global config now.
Checklist