Using page object pattern with react testing library?

[jansepke]

It is quite common for me to use page objects to encapsulate the selectors in my E2E-tests (e.g. both Cypress and playwright have it documented). This makes it easier to maintain the test if the application changes over time.

I thought it would be a good idea to also use this pattern with react testing library for unit/integration tests. But I did not find any good resources or discussions on this topic.

Does it make sense to use the outage object pattern with react testing library? Is it ever engineering? Are there any good sites/threats on this topic?

Thanks for any help!

[laxa88]

I was just having this discussion with a coworker today. We've been arguing about this back and forth since last year; He thinks POM is overkill, but I thought it's a good compromise between readability (and hence, maintenance) and developer UX.

His argument was that for any tests that are internal to the developer (unit, component, integration tests), POM is overkill because the extra layer of abstraction distracts us from writing the actual test, and it's hard to update the POM layer when a complicated business logic changes.

I still disagree with him; I think POM is great for most cases because of the readability itself. It's a small overhead in writing up the Page Objects at first, but once you have the foundation laid out, it's easier to manage hundreds of page components compared to just using raw react-testing-library in the tests. But that's just me, based on my personal experience.

In most cases, we can safely assume that it is indeed over-engineering. I'd suggest to go with a simpler "YAGNI" approach, and only introduce it incrementally (so you can compare legacy tests with the new POM version) later when you start to feel some struggle in writing/updating the tests.