--- title: "Hot libraries and heartbreak: Struggling with Cursor, RTL, and shadcn" description: "Why testing libraries can be a real pain to use." canonical: "https://momentic.ai/blog/libraries-and-heartbreak" last-updated: "2026-06-22T01:27:57Z" --- # Hot libraries and heartbreak: Struggling with Cursor, RTL, and shadcn URL: https://momentic.ai/blog/libraries-and-heartbreak [blog](/blog) [/ engineering](/blog/category/engineering) / libraries-and-heartbreak Engineering Why testing libraries can be a real pain to use. Matt Andryc Product Engineer, Gradial Writing unit tests for a wildly popular component library like shadcn/Radix UI with React Testing Library (the most popular testing framework in the React ecosystem) feels like it should be in Cursor’s wheelhouse. Like, you should be able to describe some test cases and hand off to an agent and call it a day. The reality is disappointingly complicated 😓. Here’s what feels like should be a [straightforward task](https://codesandbox.io/p/devbox/dazzling-problems-rwn5w7): testing the behavior of a popover inside a dialog. Here’s what Claude comes back with given the component above: Nothing out of place at first glance, just trying to validate the behavior shown above. And yet, even despite the effort to accommodate the popover’s content being portalled, we run into the error below: You’re gonna have to trust me that the test-ids aren’t the culprit here (or [check the sandbox](https://codesandbox.io/p/devbox/dazzling-problems-rwn5w7)). ## It's not the tool's fault This isn't meant as a knock against agentic coding tools (if they’re slowing you down, you’re probably offloading the wrong tasks). Nor is there really anything “wrong” with shadcn, Radix UI, or React Testing Library. As Andy Hook, one of the maintainers of Radix UI, [observes](https://github.com/radix-ui/website/issues/370) it’s kind of a death by a thousand cuts situation: > “There are quite a few gotchas. Especially common are pointer event firing problems and mocking layout-specific browser APIs, as JSDOM struggles with these…” I’ve found when writing unit tests to cover pretty much anything that touches @ radix-ui/react-dismissable-layer (i.e., tooltips, popovers, dialogs) with React Testing Library, sooner or later, you’re gonna have a bad time. ## When fixing one thing breaks another... `@ radix-ui/react-popover@1.1.2` Expected escape key down behavior Actual escape key down behavior Sadly, this broke several of our unit tests as `@ radix-ui/react-popover @ 1.1.2` began setting `pointer-events: none` on `document.body` when the dialog is active. So any test involving dialogs and `userEvent.Click` now gave rise to the error: `userEvent.click` from `@ testing-library/user-event` aims to simulate a realistic click, but things kind of go sideways here with JSDOM. When Radix sets `pointer-events: none` on the ``, it’s effectively telling the entire page to stop accepting pointer interactions. In a real browser, that’s fine — if you have a child element, like a dialog with a button inside it, that explicitly sets `pointer-events: auto`, the browser knows to let that button’s click event through: the hit-testing engine walks up the visual stack, understands the CSS cascade, and respects that the child has opted back in to pointer events. But JSDOM doesn’t do any of that. It doesn’t simulate visual hit-testing. It doesn’t walk the stack. It just asks for the computed style of the element you’re clicking — and sometimes, _even if the child element’s parent has `pointer-events: auto`_, JSDOM will stubbornly report `pointer-events: none` because it’s blindly inheriting the body’s setting without properly processing overrides. I ended up adopting the unsatisfactory workaround below: Disabling the pointer events check isn’t really solving the problem — it’s just telling the test to stop caring whether the element is actually clickable. We’re trading test accuracy for test passibility 🙁. ## Are these types of tests even worth it? The somewhat ironic part of using JSDOM for pointer-event interactions is that the author of React Testing Library, Kent C. Dodds, writes [_“The more your tests resemble the way your software is used, the more confidence they can give you.”_](https://x.com/kentcdodds/status/977018512689455106) The more contortions we have to make to accommodate the quirks of JSDOM, the further we get from an environment representative of real use, the less confidence we have that our tests really hold water. I’m not saying ditch unit tests altogether — pretty much anything that doesn’t involve event-driven input (i.e., user interaction) seems like fair game. But if you’re trying to test interaction, honestly, you’re better off reaching for end-to-end tests or tools like Momentic. They’re just a better fit — you’re no longer stuck bending tests to accommodate virtualized pointer events into something vaguely testable, which, let’s be real, was never going to end well anyway. ## Keep reading. [Engineering How We Ditched Postgres for ClickHouse to Process 12 Billion Caches Per Day From Postgres pain to ClickHouse speed: how we re-architected caching to serve 2M+ cache queries and 20B entries per day, while maintaining ~250ms average resolution latency. Henry Haefliger 6 min read](/blog/postgres-to-clickhouse-migration)[Engineering Most Browser Agents "See" the DOM. Ours Had to Understand User Intent. Browser agents look at the DOM. Momentic understands what the user actually meant. Here's how we scaled intent-based caching to maintain a 95%+ cache hit rate and be significantly more reliable. Henry Haefliger 8 min read](/blog/teaching-browser-agents-user-intent)[Engineering Problematic Playwright pitfalls Avoid common Playwright pitfalls that damage test stability, maintainability, and trust. Jeff An 4 min read](/blog/playwright-pitfalls) ## Close the feedback loop. Point the AI QA at your app. Free to start, no credit card. [Try for free](https://app.momentic.ai/signup) [Contact sales](/sales)