UI Framework Testing
Testing React, Angular, Vue and Knockout components — the DOM-level techniques that work across all of them, plus snapshot testing and Testing Library.
7 articles · updated 19 September 2026
Every front-end framework eventually produces DOM, and every front-end framework has its own opinion about how you should test the thing that produces it. The opinions differ far more than the outcomes.
#The one idea that transfers
Test through the DOM the way a user reaches it, not through the framework's internals. Query by role and accessible name, assert on rendered text, fire real events. Do that and a test survives a refactor, a framework upgrade, and in several documented cases an entire framework migration. Test against component state, lifecycle hooks or emitted props and it survives until Tuesday.
This is the whole thesis of Testing Library, which is why it now has bindings for React, Angular, Vue, Svelte and more. The bindings are thin; the shared query API is the product.
#Where the frameworks genuinely differ
- Angular ships a real dependency
injection container, so its
TestBedcan swap a service for a double with no library involved. It also has a change-detection model you have to drive explicitly, which is the single biggest source of confused Angular tests. - React has no DI, so doubles are installed by module mocking or by passing them in as props — see jest mocking.
- Vue sits between the two, with
reactivity that settles asynchronously and a
nextTickyou will learn about the hard way. - Knockout is old, still running large systems, and unusually testable — observables are plain functions and view models are plain objects, so most of a Knockout app can be tested with no DOM at all.
#Also here
DOM testing covers the layer beneath all of them, and is what you want when the code under test is a web component, a jQuery plugin, or anything else with no framework to help. Snapshot testing is the technique most likely to be adopted enthusiastically and regretted quietly, and the article is mostly about how to avoid the regret.
Component tests are not the same as component testing in the deployable-service sense, and they are not end-to-end tests either. They sit in the middle of the pyramid, and for most web applications that is where the majority of the value is.
Everything in UI Framework Testing
DOM Testing
foundationTesting the layer every front-end framework produces — queries by role and accessible name, event simulation, jsdom's limits, and why selector choice decides maintainability.
Testing Library
practicalThe query API shared across React, Vue, Angular and Svelte — its guiding principle, the queries, user-event, and the mistakes it is designed to prevent.
Testing React
practicalComponents, hooks, context, server components and async state — what to test in a React application, what to leave alone, and how to avoid act warnings.
Testing Angular
practicalTestBed, the change detection model that confuses everyone, HttpTestingController, signals and standalone components — testing Angular without fighting it.
Testing Vue.js
practicalVue Test Utils and Testing Library, nextTick and reactivity timing, Pinia stores, composables and the mount-versus-shallowMount decision.
Testing Knockout.js
practicalKnockout view models are plain objects and observables are plain functions, which makes most of a Knockout application testable with no DOM at all.
Snapshot Testing
practicalRecording output and comparing it on every run — where snapshots earn their place, the approval reflex that destroys their value, and better alternatives.