chore(iOS, Fabric): add tests for header interactions #2848
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maciekstosio
changed the title
kkafar
requested changes
Apr 9, 2025
Member
kkafar
left a comment
kkafar
left a comment
There was a problem hiding this comment.
The initiative is great. We definitely need this.
This looks very solid, I've just left few style-related remarks.
Great job.
|
|
||
| describe('backButtonMenuEnabled: true', () => { | ||
| describe('backButtonDisplayMode: default', () => { | ||
| it('with default text', async () => { |
Member
There was a problem hiding this comment.
Suggested change
| it('with default text', async () => { | |
| it('default back title stays visible', async () => { |
Just one note to all the tests - would be nice if the string in it better described our expectations regarding the test, so that it is more readable from terminal what the test does. I'm not claiming that my suggestion is even good, but would be nice to come up with something more readable.
Comment on lines
153
to
157
| await element(by.text('DisabledDefaultCustomText')).tap(); | ||
| await element(by.text('Open screen')).tap(); | ||
| await expect(element(by.text('Custom'))).toBeVisible(); | ||
| await expectBackButtonMenuToNotExistOnLabel('Custom'); // Check if backButtonMenu is disabled | ||
| await element(by.text('Pop to top')).tap(); // Go back |
Member
There was a problem hiding this comment.
I think this can be refactored out to a function with some parameters, right? We do not need to repeat it every single time.
| }); | ||
|
|
||
| // Custom | ||
| it('Default long back label should be truncated to generic by buckButtonDisplayMode', async () => { |
maciekstosio
changed the title
maciekstosio
changed the title
maciekstosio
deleted the
@maciekstosio/Add-tests-for-header-interactions-
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR adds tests for #2809, #1589 and #2800.
Changes
The main assumption is to test all permutation of headerBackButtonMenuEnabled, headerBackButtonDisplayMode and content of button (default - taken from previous screen headerTitle, custom from headerBackTitle and styled when there are styles applied). I hope this will help us tracking regression as this part of the code is a bit confusing and caused us problem in the past.
Additionally there are added "custom" scenarios that test default default behavior with default text and custom text (if the back button changes it's appearance depending on available space and headerBackButtonDisplayMode specification).
The some of the last cases are set to failing, and this is known disparity reported in #2809, we plan to fix it soon after, but wonted to make sure we don't cause a regression.
Remark:
I did it in a way that after each test we're returning to the screen with all test cases for 2809, this is due to the fact that scrolling through list of all Test* takes a lot and reloading RN after each test would cause huge overhead. The downside of it is that if any of the test fails if will cascade fail all other.
Test code and steps to reproduce
You can run test with:
Checklist