5 ms·

> 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? (

by jmull 2y ago

> 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.

__jonas 2y ago
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
zer00eyz 2y ago
>> 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.
bastawhiz 2y ago
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.
- Hasu 2y ago
  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.
  - bastawhiz 2y ago
    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"
- jmull 2y ago
  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.)
  - bastawhiz 2y ago
    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.
    - jmull 2y ago
      It’s a unit test framework though, not a suite of containerization software and services. Maintained mostly by one person for years.
deleted 2y ago
[deleted]
SloopJon 2y ago
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. [1] https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl
jpnelson 2y ago
This community built React 18 adapter actually works pretty well in my experience. Some failures, but worked for multiple thousands of test files for my use case. https://www.npmjs.com/package/@cfaester/enzyme-adapter-react-18 https://www.npmjs.com/package/@cfaester/enzyme-adapter-react... 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.

by jmull 2y ago

__jonas 2y ago

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

zer00eyz 2y ago

>> 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.

bastawhiz 2y ago

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.

Hasu 2y ago
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.
- bastawhiz 2y ago
  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"
jmull 2y ago
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.)
- bastawhiz 2y ago
  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.
  - jmull 2y ago
    It’s a unit test framework though, not a suite of containerization software and services. Maintained mostly by one person for years.

deleted 2y ago

[deleted]

SloopJon 2y ago

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. [1] https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl

jpnelson 2y ago

This community built React 18 adapter actually works pretty well in my experience. Some failures, but worked for multiple thousands of test files for my use case. https://www.npmjs.com/package/@cfaester/enzyme-adapter-react-18 https://www.npmjs.com/package/@cfaester/enzyme-adapter-react... 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.