react-native-testing-library icon indicating copy to clipboard operation
react-native-testing-library copied to clipboard

RNTL Roadmap v12.x

Open mdjastrzebski opened this issue 2 years ago • 7 comments

This roadmap is a proposal for development efforts for current RNTL major version. I've prepared a list of things that I have on my mind that would bring the biggest improvements to our users.

v12.x

Non breaking improvements:

1. User Event API - DONE

  • API based on current version of User Event (v14)
  • Events behavior based on experiments on iOS/Android
  • Initial scope (most common events, 80/20 rule)
    • [x] user.press()
    • [x] user.type()

2. Jest matchers - DONE

  • [x] Ship inside RNTL for better support and compatibility
  • [x] Use migration process to review the available matchers and their behaviour
  • [x] Provide gradual migration path for existing users of @testing-library/jest-native

~~3. Event handling improvements~~ - descoped in favor of User Event

  • ~~Implement default event object for fireEvent calls~~
  • ~~Expose more common events in easy for (fireEvent.xxx)~~
  • ~~Improve event simulation based on experiments~~

4. Review and improve documentation & examples

  • Identify and update stale parts of documentation
  • Update Redux example
  • Improve the structure of documentation to make it more approachable

v13

  1. Review API differences between RNTL and RTL. Use major release to introduce breaking changes that would improve the compatibility. Suggested by @AugustinLF
  2. Clean up legacy fireEvent stuff:
    1. Remove ability to invoke events by passing event handler name (onPress) instead of event name (press)

This is an initial proposal, please submit your feedback on the presented items, what is missing, etc. I'm looking forward for feedback from the RNTL team (@thymikee, @AugustinLF , @pierrezimmermannbam, @MattAgn) as well as our users and contributors.

mdjastrzebski avatar Apr 28 '23 14:04 mdjastrzebski

That looks like a good strategy to me. With the ironing of the async act updates problems + the multiple accessibility fixes mean that we're overall in a good shape.

Improving events looks like a good focus for the next releases.

Regarding further changes, it might be worth to have a look at the differences in API with RTL and see if there's something that needs to be improved (on either end) for consistency.

AugustinLF avatar May 02 '23 11:05 AugustinLF

Thanks for creating that discussion, it's a great idea!

Shipping jest native matchers in RNTL would be great! I'm also onboard with useEvent and the documentation improvements, those are really important.

However I'm not too sure on the event handling improvements. There is a need for improvement in that area for sure, but to me this is why we're creating userEvent. I think efforts should be focused on building userEvent and in the long term I see fireEvent as an API to call props but nothing more. If we add further simulation in fireEvent I think it will confuse users more on what userEvent brings and what is the purpose of both APIs

pierrezimmermannbam avatar May 04 '23 11:05 pierrezimmermannbam

Onboard with the whole strategy 🚀 Especially having the jest matchers in RNTL, people would maybe discover them more easily

Also agree with @pierrezimmermannbam on the differences between userEvent and fireEvent

MattAgn avatar May 15 '23 18:05 MattAgn

What is the best way to ship @testing-library/jest-native with RNTL by adding it as a dependency that the idea? I'm asking because I'd like to pick up this task and get my hands dirty with the library, any other low-hanging fruits?

vanGalilea avatar Aug 02 '23 10:08 vanGalilea

Hi @vanGalilea thanks for reaching out. Regarding Jest Native matchers the current plan is to work on migrating them into RNTL repo one by one, carefully examining their semantics & compatibility with Jest DOM matchers, adding and removing some of these as needed, so I would not consider this to be especially low-hanging fruit, more like a series of interesting yet tedious tasks that include both coding & research.

Another option would be to help us with User Event, a hot new feature we'll be releasing really soon. So far we have implemented press() and type() interactions, but there are other useful ones, e.g. scroll.

The process for this goes something like this:

  1. Inside our experiments app (already in the repo) create a new experiment for scroll view logging out all events.
  2. Log the event sequence on both iOS device/simu & Android device/emu and publish the results to our wiki
  3. Analyse the event sequence to find reasonable common ground between iOS & Android
  4. Add new User Event method emitting that kind of sequence.

This is probably also a mid-hanging fruit as you need to do the research and handle various edge-cases, etc. At the moment I do not think we have any real low-hanging fruits tbh. RNTL is stable and well-developed, and we put extra care not to break existing stuff, and deliver high quality stuff in the new features.

Let me know if you would like to contribute in any of the above, or perhaps you have some other idea for improvements.

mdjastrzebski avatar Aug 02 '23 21:08 mdjastrzebski

@mdjastrzebski what do you mean by semantics & compatibility with Jest DOM matchers? You'd want to align the API of jest native matchers to the one of jest dom? I haven't really thought about it at all but it could come later no? I figured the first step would be to copy the existing matchers inside the RNTL repo as is and work from there, wouldn't that be easier?

Both options have their advantages though. If we start again from scratch we don't have to care about breaking changes but at the same time it will be very hard for users to migrate and they'll probably have to use both RNTL and Jest native matchers but we can't really afford to have matchers that have the same name in both of those. If we start by just replicating Jest Native in RNTL then it enables easy migration for users and continuing to maintain Jest native matchers would maybe not be required in that case.

Overall I think I like more the approach of copying the existing into RNTL repo for a smoother transition but maybe we could start with an investigation on compatibility with Jest DOM matchers to see what changes we would eventually make and from there decide what the best option would be.

@mdjastrzebski @AugustinLF @MattAgn wdyt?

pierrezimmermannbam avatar Aug 04 '23 14:08 pierrezimmermannbam

@pierrezimmermannbam, @vanGalilea I've created a separate issue for discussing the idea of shipping Jest Native matchers with RNTL: https://github.com/callstack/react-native-testing-library/issues/1439.

mdjastrzebski avatar Aug 06 '23 16:08 mdjastrzebski

Closing as features are completed. Docs/examples could still do with some updates though.

mdjastrzebski avatar Mar 12 '24 09:03 mdjastrzebski