Direction/options for testing preact components

[bmarti44]

Hey preact team! I had a question on testing preact components, and the options currently available. I tend to be overly pedantic for clarity. Thank you for any and all help/guidance with this issue ahead of time.

It seems there are two main options (as documented on the preact website) ->

1. Enzyme (as you know, currently supported via an adapter created/maintained by the preact core team).
2. Preact Testing Library

I saw very recently that PTL is no longer maintained/looking for maintainers with a new open issue

Without a maintainer for PTL, I'm reluctant to use it. The other option recommended on the preact website is enzyme, and there are several concerns that I have for using enzyme stemming from this article. While the most convincing points seem to be related to the refactoring of the adapters for new versions of react (which does not seem to be a problem for preact, as you maintain the adapter) there are several other concerning points that the article points out, specifically ->

1. AirBnB moved enzyme over to an external github org in February 2020. They promised to continue to make updates, but did mention RTL had gained a lot of traction with AirBnB.
2. There is only one person maintaining enzyme
3. Enzyme was last published 2 years ago
4. The react ecosystem has largely started to move away from using enzyme and recommended RTL.

I've tried to keep the above argument tied to KPI's instead of personal opinion to illustrate why some people may be hesitant to use enzyme, especially those already familiar with react but looking to start using preact.

With all of that typed out, my questions finally is... What should preact developers be using for testing? Is there another option that is recommended beyond the two that I've covered/present on the preact website?

Again, thank you for your time and help, it is truly appreciated!

[mikerob215]

I've run into this myself and have used code from an unmerged PTL pr in a custom render function to get it working. Using dom testing library directly would be a non enzyme alternative, outside of that, without a maintainer for PTL, enzyme might be the only choice.

[JoviDeCroock]

I have sent a message on PTL to take over maintenance, personally I often use cypress for all my testing needs example here allthough ideally we would add cypress component testing support as well. Let me look into that

https://github.com/cypress-io/cypress/tree/develop/npm/react

[robertknight]

I'll lend my perspective as the person who has been doing most of the maintenance on the Preact Enzyme adapter, but also someone who has been using Enzyme + Preact at work for three years on projects that have now accumulated thousands of tests.

I think the most useful distinction to understand between Testing Library and Enzyme are the UI trees they operate on. Testing Library's API queries and operates on the rendered DOM tree. Enzyme's API queries the rendered component tree, with the ability to access DOM nodes if you need to. These differences have consequences for writing tests and ongoing maintenance.

In terms of writing tests, Testing Library is focused more on integration tests (this blog post from the original author gives some context), Enzyme more on unit tests. For "leaf" components in the tree, this doesn't make a big difference. For components higher up the tree, Enzyme has the advantage that you can query the rendered children and the props passed to them. This means that you can express tests at this level of abstraction (eg. if a ShoppingCart component is passed a list of 10 items to render, it should render 10 CartItem children with appropriate props). The tests for the parent component can be simplified/optimized by mocking complex children. See this blog post for ways of doing that.

Enzyme originally pushed developers more towards the "extreme" end of the unit testing spectrum by recommending the use of React's shallow rendering APIs to render only one level deep, and not render actual DOM nodes. This turned out not to work well because "one level deep" of React components doesn't necessarily correspond to a logical unit in an application, and a lot of tests really do need an actual DOM. I still think Enzyme's ability to interact with the UI tree on the component level is useful, but I recommend always using normal DOM rendering, and doing any mocking using similar approaches as for non-UI code (see blog post). This makes unit <-> integration tests more similar and more of a spectrum that you can shift between as appropriate, instead of a binary choice. To sum up this paragraph, I think there is a right way to use Enzyme that works well, but the documentation/APIs originally pushed towards practices that led to brittle tests. Testing Library didn't present developers with this choice.

From an ongoing maintenance perspective, Testing Library's approach does have the significant advantage that only a minimal amount of framework-specific code is required, since much of the code lives in the @testing-library/dom package. PTL has < 200 lines of code. As such I think it is very safe from a future-maintenance perspective. Testing Library's small API surface area and well presented website are also plus points for long-term usage and onboarding developers into a codebase that uses it.

Enzyme's approach does require more framework specific code, though that all lives in the adapter. I think the problems that Enzyme had with not being able to keep up to date with React is partly a reflection of implementation choices in Enzyme, partly due to React being far more complex internally than Preact, and partly a social problem of not collaborating with the React team to find a minimal, reasonably stable API that would allow Enzyme to query the component tree. Preact's Enzyme adapter adopts a number of technical and social/organizational strategies (eg. it is part of this org) to try and keep it easier to maintain.

[bmarti44]

Thank you so much for the detail responses, truly appreciated! We have a preference on our team for PTL, and with it being a very small wrapper of < 200 lines, and @JoviDeCroock now maintaining it, we feel very comfortable with using it.

Cypress is excellent, we use it as well for more functional/e2e testing, also in conjunction with cypress testing library.

I feel like I can't thank you enough for all of the hard work you've put in on this project and the extremely well thought out and thorough responses. Closing this ticket.