Ability to traverse host component tree easily (discussion)

[mdjastrzebski]

Describe the Feature

Currently the render tree provided by render method consists of both host (e.g. View) and composite components (class & functional components). All query methods generally ignore composite components, and return only host components, in order to simulate RN runtime env. However, when using parent & children properties of ReactTestInstance developer using RNTL is exposed to them.

RN/TL provided abstraction over component tree wrapping host components' ReactTestInstance with NativeTestInstance in order to allow parent & children traversing.

RTL does avoid this problem, as it renders using React DOM with JS DOM as runtime env, which leaves only HTML components (which could be equal to host components).

Originally this was raised by @TAGraves in #477:

parentNode is undefined (see https://www.native-testing-library.com/docs/api-test-instance#parentnode) -- this one is really important for us as we use it a lot for testing styles in cases where we can guarantee what the "native" parent will be. From a quick check I'm not sure if there is a new equivalent (.parent behaves differently since there's no concept of a NativeTestInstance now)

Possible Implementations

1. Provide component tree consisting only of host components. This might prove complex due to need to rewire various event handler props like onPress from composite components.

2. Provide additional properties (e.g. parentNode, childNodes?) that will skip composite components.

3. Discourage using parent and children traversing in favor of higher level abstraction, that better matches 'what the user sees' philosophy. children traversing can be quite easily replaced with within in many cases. However, there is not easy replacement for ancestor traversing.

4. Build some kind of npm package to focus on simulating RN runtime env, just like JS DOM simulates browser env. It would probably be on React Test Renderer. With this, we could move some runtime env. simulation features from RNTL to that package.

Related Issues

#477

CC: @thymikee, @TAGraves, @cross19xx

@TAGraves could you describe major testing cases which were using parentNode traversing, so we can discuss the use cases in more concrete way?

[thymikee]

Something that I noticed recently is that UNSAFE_ queries rely on traversing composite components. Some users rely on this behavior when "unit testing" their components (check if this type of component have certain props).

As such, I'm leaning towards creating (re-creating?) an abstraction on top of ReactTestInstance that would encourage traversing host components and still allow for those "unsafe" use cases.

[Findiglay]

We were using some parentNode traversing with RN/TL to assert that some components such as inputs were in the correct validation state, given a certain input e.g. select input, change text, traverse to input error message - confirm that text and text color are correct etc.

I think using snapshots would make sense here in a component unit test, but for form integration tests (that combine data, multiple inputs and validation steps) I would rather avoid snapshots and simply traverse the dom to confirm some key details.

Perhaps there is a better approach?

What I preferred about RN/TL was that it rendererd an abstraction that was closer to what user would see, so making assertions that were user-oriented were easier. I would rather test outcomes like colors than implementation details like a "valid" prop. This is still often (not always) possible with the RNTL dom rendering, but makes testing like this more difficult.

[mdjastrzebski]

Closing as stale.