Look into the future of React Native Testing Library

React Native Testing Library adapts the Testing Library approach for React Native, using React Test Renderer rather than DOM APIs. Mikhail says the helpers grew out of the difficulty of writing tests with the renderer directly and concerns that Enzyme made it easy to test implementation details. The library aims to help tests reflect how people use an app.

Mikhail walks through rendering a component, finding elements by text or accessibility labels, and firing events such as changing text or pressing a button. He highlights accessibility labels as a way to test that elements can be found by users of assistive technology. The library also offers query variants: `getBy` throws when nothing matches, `queryBy` returns null, and `findBy` waits for an element to appear.

Testing Library tests use user-like queries and interactions in an emulated JavaScript environment, without running an emulator. Mikhail describes end-to-end tools such as Detox as useful for checking that the full app works across its systems, while noting that more systems involved can mean more things go wrong. He presents the two approaches as serving different purposes.

Mikhail describes React Native Testing Library and the later official Testing Library for React Native as separate implementations with similar APIs. He says their approaches to native mocks and maintenance differ, and that his library aims to keep its layer over React Test Renderer thin. Version 2, released a few weeks before the episode, brought its APIs closer to other Testing Library projects and began addressing the divide, though a migration strategy was still needed.

Version 2 added automatic cleanup and aligned wait APIs with Testing Library, including wrapping `waitFor` calls in `act`. It removed shallow rendering and `getByName`, and renamed implementation-detail queries such as `getByType` to `unsafe_getByType`. Mikhail also recommends `findBy` or `waitFor` instead of `flushMicroTasksQueue`.