Lots of negativity in the comments but I think the solutions outlined really interesting and valuable! There are some idiosyncrasies around unit testing ui that are just hard to work around. And the issues with e2e tests in the context of testing individual UI pieces are totally valid too.<p>The one thing that at least initially rubs me the wrong way is how the overrides work. Like I get why that's a solution to how we can inject some data, but I don't like the idea of writing test-specific code in a component just to enable tests with this tool. That being said, I've done similar things in the past when I've run out of options and this looks pretty clean, I just wonder if there's another way.
> Conversely, using integration testing tools like Cypress or Playwright provides control over the page, but sacrifices the ability to instrument the bootstrapping code for the app. These tools operate by remotely controlling a browser to visit a URL and interact with the page.<p>I don't think the author has used Cypress or Playwright. Their real value is that they do not drive browsers from the outside like slow, flakey WebDriver. They also allow injecting test doubles. And to override app functionality (not having to wait for a "normal" 60 second timeout like the author hypothetically suggests).<p>This test framework seems to solve non-problems.<p>Is Netflix not quite so FAANG these days?
I've always wanted to build a UX tester that uses accessibility tech. We get to test both at the same time, and it might make the accessibility tech saner and easier to use also.
I think this is overselling itself a little. It seems genuinely useful to be able to do more expansive integration tests of components, and combinations of components, especially running in real browsers. But that’s only really an incremental gain over component unit tests with mocks. In the case where you own a very complex SPA with multiple back end dependencies you don’t control, then yeah, maybe this is all you need. But I don’t see how this can replace real end to end functional tests in most apps.
Needing to change the application code to mock things rubs me the wrong way. I 100% do agree with the frontend testing challenges they lay out in the beginning of the post though.
My initial impression of this is that it enables controlling just how much of the app you want to render for your test, while more traditional solutions force you towards either rendering the whole app or testing just a component. Is that accurate?
I've said it before, and I'll say it again: Interfaces used by humans must be tested by humans. These can either be your staff, or your customers.<p>Yes that does mean wading through each interaction pathway every time you make a release, there really is no substitute.
Are there potential performance issues to consider with overrides - I'm supposing<p>const FetchPerson = createOverride(fetchPerson);<p>must be less performant by some amount than just using fetchPerson? How many over-rides do you find a reasonably complex component needs?
how many billions of dollars and they still host their blog on a nagware site SMH It's not like moving would be high drama since they already have a custom domain for it<p><a href="https://scribe.rip/introducing-safetest-a-novel-approach-to-front-end-testing-37f9f88c152d" rel="nofollow">https://scribe.rip/introducing-safetest-a-novel-approach-to-...</a>