FAQ
Below are some commonly asked questions about using Atomic Testing.
How do I start using Atomic Testing?​
The quickest path is the create atomic-testing scaffolder — run it in an existing project and it detects your framework, runner, and UI library, then writes a runner config, an example component, its ScenePart, and a passing test. Prefer to wire things up by hand? Install the packages for your test environment and UI library, define SceneParts for the components you want to interact with, and create a Test Engine instance; the Getting Started Tutorial walks through those steps.
Which UI frameworks are supported?​
Atomic Testing is framework-agnostic — the same drivers run under React, Vue, Angular, Playwright and plain DOM tests. Drivers ship for popular component libraries including Material UI, MUI X, Angular Material, Radix and shadcn/ui. You can also create drivers for your own component library if one is not available.
Does Atomic Testing replace React Testing Library?​
No. Atomic Testing uses @testing-library/dom under the hood for DOM interactions — the same framework-agnostic library React Testing Library itself builds on, not RTL directly. It layers reusable component drivers and the TestEngine on top, which is what lets the same drivers work across React, Vue, Angular and Playwright rather than just React. See Atomic Testing vs React Testing Library for details.
Can I use it with unit tests and end‑to‑end tests?​
Yes. Drivers work the same way in Jest/Vitest component tests and in Playwright end‑to‑end tests, so the same driver code can be reused across test types.
How does Atomic Testing handle asynchronous UI behavior?​
Driver methods return promises and rely on the underlying test framework’s wait utilities. You can await each call so tests stay stable even when the UI updates asynchronously.
Do I need to rewrite all my existing tests?​
No. You can adopt Atomic Testing gradually and keep legacy tests in place. New tests can be written using drivers while older tests continue to run as before.
What benefits does Atomic Testing provide to my team?​
Component drivers encapsulate how to interact with the UI so tests remain focused on intent rather than implementation details. This leads to easier maintenance and helps reduce flaky tests across projects.
Does adopting Atomic Testing require a specific test runner?​
No. The library works with popular tools such as Jest, Vitest and Playwright. Choose the runner that best fits your workflow.
What is the difference between "verified" and "experimental" support?​
A verified framework-runner-design-system combination is backed by a green fixture in this repo, so the scaffolder writes it with confidence (React + Jest and Vue 3 + Jest, plus their design systems). An experimental combination is composed best-effort with no proving fixture yet — anything on Vitest, Angular, or Playwright — and create atomic-testing prints a warning before writing one. The Framework and Runner Support page has the full explanation and lists every combination and its tier.
Why does Angular run under Vitest browser mode?​
Angular's change detection needs a real browser environment, so Atomic Testing supports it under Vitest browser mode (and Playwright) rather than jsdom. Angular + Jest and Angular + jsdom Vitest are intentionally not enabled — the scaffolder refuses them with a clear message. See the support matrix for the offered Angular combinations.
How can I create drivers for my own component library?​
Implement a driver that exposes the actions and assertions relevant to your components. Drivers can live in a separate package so consumers can install them alongside your UI library.
Can I contribute drivers back to Atomic Testing?​
Yes. Contributions are welcome. Feel free to open an issue or pull request to discuss adding official support for your component set.