-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add E2E tests for Pressable component #2
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this is exactly needed, but it is possible to add more test cases. For example, the Pressable feedback events example could be tested out by simulating taps + long presses. Detox has a method for the latter too. Also, the disabled pressable can be tested by hooking it up to an alert of some kind (or any indication that the pressable has been pressed will do - this can be a text component as well).
@AnshG714 , thanks! I'll have a look at the docs.
This makes sense. I'll add it immediately! 🖖
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stealthanthrax the code looks great! Same test naming comments as on the other PR apply here, would like to see these conform to the it should...
naming, and have the test descriptions focus on the RN Component under test, and not on the test screen elements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good, one minor typo fix in suggestions
Co-authored-by: Jani Eväkallio <[email protected]>
Summary: While in theory we should never delete views before removing them from the hierarchy, there are some exceptions: (1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent: (2) When deleting views as part of stopSurface. On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it. On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D22321374 fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
Summary
Fixes #1
Added E2E tests for the pressable component.
Changelog
[IOS] [Added] - Integration test for the pressable component
Test Plan
On running the following commands
The output is as shown below: