Skip to content
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

API proposal: Jest Native matchers migration #1468

Closed
18 of 19 tasks
mdjastrzebski opened this issue Aug 22, 2023 · 10 comments
Closed
18 of 19 tasks

API proposal: Jest Native matchers migration #1468

mdjastrzebski opened this issue Aug 22, 2023 · 10 comments
Assignees

Comments

@mdjastrzebski
Copy link
Member

mdjastrzebski commented Aug 22, 2023

API proposal for Jest matchers migration

This issue describes the desired API regarding Jest matchers to be included in RNTL package, and that should replace the Jest Native package matchers.

Problems with the current Jest Native matchers:

  • lack of maintainers
  • inconsistent RN env simulation vs RNTL
  • potential version mismatch between JN and RNTL packages
  • matchers frequently relying on RN implementation details prone to break in case of RN change

The goals of this initiative are as follows:

  • Bring non-maintained Jest Native matchers into well-maintained RNTL project
  • Tie matchers to RNTL release hence preventing matcher incompatibility, full test coverage
  • Review and improve internal matcher implementation, align behaviour with RNTL
  • Add missing matchers, based primarily on Jest DOM matchers
  • Provide gradual migration path for existing users of @testing-library/jest-native

Matchers to keep

Matchers to change signature

Matchers to add

Matchers to remove

  • toHaveAccessibilityState - to be replaced by toBeDisabled, toBe(Partially)Checked, etc

Migration path

  • Create RNTL documentation for matchers
  • Create migration guide
  • Expose legacy export in Jest Native package
  • Update Jest Native docs that it is deprecated
  1. Jest Native package will allow for importing existing matchers with legacy prefix, so that users will avoid name clashes on expect function. This will be provided by Jest Native and not the RNTL in order to avoid having to managed that code inside RNTL and to keep it in the final state for potentially long time.
@mdjastrzebski mdjastrzebski changed the title API proposal: Jest Native Matchers API proposal: Jest Native matchers migration Aug 22, 2023
@MattAgn
Copy link
Collaborator

MattAgn commented Aug 22, 2023

Fully agree with all of the above! I'll try to take one or two tasks when i come back from vacation in a week or so.
Quick naming question: why go for toHaveAccessibleName instead of toHaveAccessibilityLabel or toHaveAccessibleLabel to stay coherent with the prop name?

@pierrezimmermannbam
Copy link
Collaborator

That seems perfect! Great work @mdjastrzebski !

@mdjastrzebski
Copy link
Member Author

Update: Jest Native package includes legacy extend as of 5.4.3 🚀🎉

This is not yet publicly documented, that will be done after we complete RNTL matcher migration.

In order to use legacy extend expect(...):

  1. Use import '@testing-library/jest-native/legacy-extend-expect instead of import '@testing-library/jest-native/extend-expect
  2. Use expect(...).legacy_toXxx matchers instead of expect(...).toXxx.

In the default setup nothing changes, so you need the changed import to enable legacy_toXxx matchers.

@AntoineThibi
Copy link
Contributor

Hello !
I created a PR for toHaveProp matcher : #1477

facebook-github-bot pushed a commit to facebook/react-native that referenced this issue Aug 30, 2023
Summary:
Note: this PR is related only to testing mocks provided by RN, and does not affect runtime code.

When building new Jest matchers for React Native Testing Library (callstack/react-native-testing-library#1468) I've noticed that when rendering React Native in Jest using React Test Renderer the mocked `Modal` component renders host `Modal` element when `visible={false}`.

This seems to be incorrect as only visible modal should render any host elements. Not visible one should not render any host element even empty ones. Current mock implementation also contradicts the behaviour of non-mocked `Modal` which does not render `RCTModalHostView` in such case.

## Changelog:

[General] [Fixed] - Do not render mocked <Modal /> when `visible=false`

Pull Request resolved: #39157

Test Plan:
I've added test showing that non-mocked Modal renders to `null` and modifies the existing tests so that mocked Modal also renders to `null.`

Luna: I've updated relevant snapshots

Reviewed By: NickGerleman

Differential Revision: D48728277

Pulled By: lunaleaps

fbshipit-source-id: cf06495ad959e2d9549241b57f46f75d7beb9eae
@hduprat
Copy link
Contributor

hduprat commented Sep 7, 2023

Hi everyone,

Here is a PR for the toBeBusy() matcher: #1493

@AntoineThibi
Copy link
Contributor

Hello !

Here is one for the toBeSelected() matcher : #1488

@siepra
Copy link
Contributor

siepra commented Sep 11, 2023

Hi, is anyone currently working on toContainElement or am I free to go?

@mdjastrzebski
Copy link
Member Author

@siepra go ahead, it's yours now.

@siepra
Copy link
Contributor

siepra commented Sep 13, 2023

Here is also a PR for the toBeExpanded() matcher: #1497

@mdjastrzebski
Copy link
Member Author

🎉 Available in version: v12.4.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants