> saving considerable developer time of at least 22% of 10,000 hours
I wonder how much time or money it would take to just update Enzyme to support react 18? (fork, or, god forbid, by supporting development of the actual project).
Nah, let's play with LLMs instead, and retask all the frontend teams in the company to rewriting unit tests to a new framework we won't support either.
I guess when you're swimming in pools of money there's no need to do reasonable things.
Slack's blog post links to "Enzyme is dead. Now what?"[1], in which Wojciech Maj said, "A couple of tireless evenings later, @wojtekmaj/enzyme-adapter-react-17 was born." Now, he was building on someone else's pull request, and he also said that adapting to React 18 would have required a huge rework. Still, I'm thinking that @slack/enzyme-adapter-react-18 just might have taken less than 10,000 hours.
Then again, the idea of a testing framework that is so tightly coupled that it breaks every version is foreign to me, so I probably don't know what I'm talking about.
>> by supporting development of the actual project
You mean good engineering.
>> play with LLMs instead
You mean good on the resume.
>> I guess when you're swimming in pools of money there's no need to do reasonable things.
We dont. Reasonable sailed when FB/Google/AMZN started "giving back" to the community... They leaked out all their greatest examples of Conways Law and we lapped it up like water at a desert oasis.
The thing is, these technologies have massive downsides if you aren't Google/FB/Amazon... But we're out here busy singing their praises and making sure jr dev's are all pre trained out of college for the FA(not this one)ANG lifestyle.
Think about how much react being public saves Facebook on onboarding a new dev.
When I read 'React testing library' I thought they had added an official testing library to the React project which would have been fantastic and a worthwhile migration target for sure, sad that it's just another third party one which also might one day stop supporting newer React versions
That said, making the 19 adapter is a whole new task, and I think these tests should be converted to RTL eventually, so the approach described in the blog post is still valuable.
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"
I wonder how much time or money it would take to just update Enzyme to support react 18? (fork, or, god forbid, by supporting development of the actual project).
Nah, let's play with LLMs instead, and retask all the frontend teams in the company to rewriting unit tests to a new framework we won't support either.
I guess when you're swimming in pools of money there's no need to do reasonable things.