RN Web support

[mdjastrzebski]

RN vs RN Web comparison

RN Web renders HTML elements like <div> instead of typical RN host views like <View />, <Text />.

// Testing code
const renderer = TestRenderer.create(
  <View>
    <Text>Test</Text>
  </View>
);
expect(renderer.toJSON()).toMatchSnapshot();

// RN Output
<View>
  <Text>
    Test
  </Text>
</View>

// RN Web Output
<div
  className="css-view-175oi2r"
  dir={null}
>
  <div
    className="css-text-146c3p1"
    dir="auto"
  >
    Test
  </div>
</div>

This can be replicated by installing jest-expo package and applying Jest "preset": "jest-expo/universal". Using is the Jest Expo package is the only known popular way to render in RN Web mode I am aware of.

The comparison above has been achieved using React Test Renderer, since RNTL's detectHostComponentNames() function throws error when running under web preset.

Potential solution

React.js (web) has a mature testing solution in form of RTL, on which RNLT is modelled. However, as noted in our docs, RTL has much better testing environment due to usage of Jest DOM package, which is a reliable browser DOM simulation. In contrast, RNTL contains code simulating only the key aspects of RN env, sometimes in a very crude way.

Therefore, our recommendation so far, has been to test RN Web rendering using a proper RTL setup. This has two major downsides:

1. It's a more complex setup for the user
2. It requires user to write and maintain two sets of tests: one for RN using RNTL, and another for RN Web using RTL.

In order to ease life of RN Web users, we could potentially include proper RN Web setup inside RNTL. The env setup could be modelled on Jest Expo package (or simply re-use it). That would solve pain no. 1.

In order to solve pain no. 2, we would have to be able to execute given test suit in both RN+RNTL and RN Web+RTL+Jest DOM setup. The easiest, but not easy, way to achieve it would be create a adapter/facade layer, that would expose the familiar RNTL API to the user, but would internally translate it to RTL calls. This should be possible as, RNTL API is largely coherent with RTL API. There are some semantic differences between the queries which would need to be bridged by such RNTL adapter. E.g., RNTL exposes includeHiddenElements option which is an alias to hidden option in RTL, but RNTL exposes it on all queries, while on RTL it's only available on *ByRole queries.

Alternative approaches

1. Recommend users to test the core RN (not yet translated to Web) using current RNTL. This is what we support now. It does provide a unified testing ground for RN apps, by mixing together various iOS and Android observed runtime behaviours, but does not allow for testing of RN Web-specific aspects.

2. Provide example setup for devs wanting to test RN Web using RTL+Jest DOM, but without ability to share testing code. Users would have to duplicate their tests manually. RTL testing code would be largely copy-paste from RNTL with minor tweaks, but that the burden of maintaining RNTL/RTL differences would be on the users.

3. Create and maintain an external RNTL Web package, that would do support the API adaptation described above, in a similar way that RN Web exposes RN APIs. This could be maintained either by RNTL team or by some 3rd party with serious interest in RN Web support.

Considerations

The decision whether to pursue this effort inside RNTL should be based on the following factors:

1. Demand from the users to test RN Web apps using more realistic Jest DOM setup
2. Cost of creating and maintaining such adapter code in relation to RN & RN Web evolution.

CC: @thymikee, @AugustinLF, @pierrezimmermannbam, @MattAgn

[pierrezimmermannbam]

I agree very much with the first downside you identified but I'm not sure I understand your solution. What would it mean to include RNWeb support into RNTL exactly? I don't think there really is a way around having a test setup for RN and another for RNWeb because you don't want to use the same preset and also not the same environment (node vs jsdom). Maybe there would be solutions to make that setup easier though, that's definitely worth exploring.

You could however run the same test files using two different environments if RNTL supported a web setup, probably by mapping to RTL's APIs like you suggested. That being said I have some concerns about this approach:

• The most important one is I'm not really convinced that the second downside really is a downside. The way I think apps that use RNWeb should be tested is testing fully shared components using RNTL and only test code that's platform specific with both test setups. In those cases (which are usually not that frequent) it's also likely that the functional behavior is different so having two tests anyway would make sense. If you wanted all your tests to be for both platforms then it would indeed be very hard to maintain but I don't think it would be very beneficial. Also If you want to write tests for the web, they would be better written with RTL which has web semantics (for instance userEvent is pretty different).And if we added a an additional layer of abstraction it could make debugging web tests very hard
• I fear that maintaining this adapter could be very hard and it would introduce a coupling between RNTL and RTL's versions (and also testing library user event). It would probably need to be a separate package then but it would have 3 peer dependencies and pretty strict requirements for versions probably

[mdjastrzebski]

• iOS/Android under Jest Expo is essentially the same as RNTL runtime env, with returning ios or android in Platform.OS, Platform.select and picking .ios.ts/.android.ts files when available. So here the single test approach is working.

• Web/Node affects the above as well, but also swaps react-native for react-native-web which results in rendering divs instead of Views. Here the tests are failing due to detectHostComponentNames() failing.

[AugustinLF]

A bit late to the party, but what you're describing is what we've been doing for quite a bit where I work, we have thousands of tests that run on both web and native.

We've been doing that before using RNW (we had our own UI primitives abstracting the platform differences) but since we're now starting to using RNW, it gets even more obvious how "writing tests once" is what we need.

We do indeed are small facade library that branches to either RTL and RNTL based on the platform. Most things work out of the box (especially once you start switching to aria-* from accessibility*, but you do end up hitting some confusing stuff once in a while. For instance reported earlier this week, a difference in toHaveTextContent that I reported in #1613.

I fear that maintaining this adapter could be very hard and it would introduce a coupling between RNTL and RTL's versions (and also testing library user event). It would probably need to be a separate package then but it would have 3 peer dependencies and pretty strict requirements for versions probably
I do agree with @pierrezimmermannbam here, at Klarna we don't support the entire API of the testing-library ecosystem, and can easily control the different version, but that's already not that simple.

And to add to the point I raised in #1613 , if providing such an abstraction is something we're looking into, we'll have to sit with the folks from RTL. Every API difference is going to be a PITA, and lead to confusion for users.

[mdjastrzebski]

@AugustinLF would it be possible to open source your wrapper library? 🐱

We could either add it to RNLT or as separate repo (React Native Web Testing Library?) we could direct our users to.

[AugustinLF]

Aha, our implementation is very thin, only covers a small part of the API. I wouldn't be able to get the internal support for long term maintainability on our end, but I'd be happy to help creating something in this repo (or another one).

I can't commit to properly own the maintenance of it, as you well know, OSS takes a lot of time, and I don't have that.

[mdjastrzebski]

I totally understand that 😉 Let's see what you got and then we can think about best way moving forward 👀

[mdjastrzebski]

Closing due to the lack of interest.