Testing Across Frameworks

Course 1 · Ch 7
Testing Across Frameworks
Vue Test Utils, Angular's TestBed, and Svelte Testing Library — the same philosophy, four different APIs

Chapters 2–6 built deep, React-specific fluency with Testing Library. This chapter steps back: the same underlying philosophy — test like a user, not the implementation — shows up in Vue, Angular, and Svelte's own testing tools too, at varying distances from RTL's exact API. This site already has complete courses for all three frameworks; this chapter connects to them directly rather than re-teaching them.

Vue Test Utils

Vue's own official testing library, conceptually the closest of the three to RTL — mount() renders a component into a test environment, returning a wrapper to query. Vue's own community has increasingly adopted @testing-library/vue, a Testing-Library-flavored wrapper providing the exact same getByRole/getByText query style used throughout this course:

// @testing-library/vue — same query style as React import { render, screen } from "@testing-library/vue"; render(Greeting, { props: { name: "Ada" } }); expect(screen.getByRole("heading")).toHaveTextContent("Hello, Ada"); // vs. raw Vue Test Utils — CSS selectors, the exact anti-pattern from Ch.1/3 const wrapper = mount(Greeting, { props: { name: "Ada" } }); expect(wrapper.find(".greeting-heading").text()).toBe("Hello, Ada");

Angular's TestBed

A fundamentally more ceremonial approach — Angular's dependency-injection-driven architecture means testing a component typically requires configuring a TestBed module (declaring the component, its dependencies, mock services) before it can even be instantiated:

await TestBed.configureTestingModule({ declarations: [GreetingComponent], }).compileComponents(); const fixture = TestBed.createComponent(GreetingComponent); fixture.componentInstance.name = "Ada"; fixture.detectChanges(); // Angular's change detection doesn't run automatically in a test

This is noticeably more setup than RTL's single render() call — a direct consequence of Angular's DI-heavy architecture, not a difference in testing philosophy. @testing-library/angular exists specifically to wrap this ceremony behind a more familiar render() + screen API.

Svelte Testing Library

@testing-library/svelte is the closest of all three to React's version — Svelte's compile-time component model needs neither Angular's DI ceremony nor Vue's separate wrapper API. render(), screen, and fireEvent/userEvent work almost identically to every example in Chapters 3–6.

The Pattern Across All Four

React's virtual DOM, Vue's reactive templates, Angular's DI-plus-zone-based change detection, and Svelte's compile-time approach are genuinely different component models under the hood. Despite that, every major framework's testing ecosystem has converged, to varying degrees, on the same Testing-Library-popularized idea: query by role/text/label, fire realistic events, assert on user-visible outcomes. Chapter 3's philosophy isn't a React quirk — it's closer to an industry-wide norm for component-based UI testing.

FrameworkNative ToolTesting-Library FlavorSetup Ceremony
React—@testing-library/reactMinimal — render()
VueVue Test Utils@testing-library/vueMinimal
AngularTestBed@testing-library/angularHeavier — DI module setup
Svelte—@testing-library/svelteMinimal

Vue

Vue Test Utils (wrapper.find) or @testing-library/vue (getByRole) — both common in real codebases.

Angular

TestBed + fixture.detectChanges() natively; @testing-library/angular hides the ceremony.

Svelte

@testing-library/svelte — nearly identical to React's API, thanks to Svelte's simpler compiled model.

The Constant

Query by role/text/label, fire realistic events, assert on outcomes — true across all four ecosystems.

The Practical Takeaway
Knowing RTL from this course makes Vue's and Svelte's Testing-Library variants a very short hop — same queries, same events, same philosophy. Angular's TestBed ceremony is the one genuinely different thing to learn, and it's rooted entirely in Angular's own DI architecture (the site's Angular course covers this architecture directly), not in a different idea about what makes a good test.
Don't Assume Every Codebase Uses the Testing-Library Flavor
Plenty of existing Vue and Angular code — and plenty of tutorials — still use raw Vue Test Utils' wrapper.find('.class') style or bare Angular TestBed + fixture.debugElement.query(By.css(...)). Recognizing both styles matters when reading real, existing test suites, not just when writing new ones from scratch.

Coding Challenges

Challenge 1

Rewrite this chapter's raw Vue Test Utils example (wrapper.find('.greeting-heading')) using @testing-library/vue's getByRole instead, and explain what's gained by the rewrite.

📄 View solution
Challenge 2

Explain why Angular's TestBed setup is more involved than React's render() call — specifically, what Angular architectural feature (covered in this site's own Angular course) makes that extra ceremony necessary rather than accidental.

📄 View solution
Challenge 3

In your own words, explain why "component-based UI testing has converged on one philosophy across frameworks" is a stronger, more useful claim than "React Testing Library is a good tool" — referencing what this convergence tells you about testing skills you build in one framework.

📄 View solution

Chapter 7 Quick Reference

  • Vue — Vue Test Utils (wrapper.find) or @testing-library/vue (getByRole) — both used in real codebases
  • Angular — TestBed.configureTestingModule + fixture.detectChanges(), or @testing-library/angular to hide the ceremony
  • Svelte — @testing-library/svelte, nearly identical to React's API
  • Angular's extra setup ceremony comes from its DI architecture, not a different testing philosophy
  • The constant across all four: query by role/text/label, fire realistic events, assert on user-visible outcomes
  • Real codebases mix raw native-tool style and Testing-Library style — recognize both
  • Next chapter: Integration & Coverage — testing multiple components together, coverage thresholds, and accessibility testing with jest-axe