Enzyme is kind of dead, so it would mean picking up sponsorship and maintainership (indefinitely) rather than a one-off project to convert to the official testing library for the ecosystem.
Well, it might get a lot less dead with a small fraction of the resources spent on this project.
> indefinitely
You’ll note they’ve switch to another open source framework which has the same potential to fail without support/resources. They’ve kicked the can down the road, but are now accruing the technical debt that lead to this effort exactly the same as before. Since that technical debt will inevitably turn into a real expenditure of resources, they are stuck with expenses indefinitely, however they do it. Though I think it’s pretty obvious that one way is a lot cheaper and less disruptive to the business than the other.
(BTW, if they were concerned with indefinite expenses, you might also wonder why they want to continue to build their product on the shifting sands that are react, or pursue a unit testing strategy that is so tightly coupled to specific versions of their UI framework. These are “fuck-the-cost” decisions, both short term and long term.)
In fact, enzyme didn't support the previous version of React either, except for the grace of some random guy who wrote a driver to make it work. Airbnb, who built and maintained enzyme, abandoned it. There's (afaik) no way to add React 18 support without major changes to the enzyme core. So not only is this a problem that will plague them indefinitely (that is, dealing with their test framework not supporting a recent version) if they don't switch, it's adopting a project that they don't own and didn't start to avoid a one time cost of rewriting some tests.
> Since that technical debt will inevitably turn into a real expenditure of resources, they are stuck with expenses indefinitely, however they do it.
I simply can't see how becoming the maintainer of a testing framework to rewrite it to add support for the last two versions of the library it no longer works with is a comparable investment to the ongoing cost of maintaining your own unit tests. That's like if Docker became abandoned and didn't update to support modern kernels so you decided it's better to become the maintainer of Docker instead of switching to Podman.
"It was just maintained by one person" has no bearing on the cost of maintaining.
> It’s a unit test framework
It's not a unit test framework. It reaches into the internals of React to make it behave as though it's running in a real environment. It requires intense knowledge of how React works under the hood, and the design requires it to be compatible with lots of old versions of React as well as the latest version.
Honestly I'm not sure why you are so dismissive of the incredible amount of effort that's gone into making it work at all and how much effort it would take it make it work for the latest version of React.
react-testing-library isn't the "official testing library" for React, it isn't made by the React team, and testing library provides testing libraries for other frameworks.
It's just a change from an outdated, unmaintained testing library to a more 'modern', well-maintained library. There are also some philosophical differences in the testing approach.
Monster Energy is the official energy drink of NASCAR but that doesn't mean NASCAR manufactures energy drinks. As best as I can tell, RTL is the only testing framework mentioned in the React docs, so that's pretty "official"
