Testing with Component Harnesses for the Win
summary
Claim: component harnesses provide a stable, high‑level API that works for unit and end‑to‑end tests so tests stop leaking DOM selectors. The talk shows a working harness pattern implemented in Angular Material CDK and reused across Cypress, Protractor and Jasmine testbeds, with a test reduced to four lines of code. The harness loader selects components by type, exposes typed methods, insulates tests from DOM changes, and the examples run successfully both in isolated fixtures and in the browser.
AI-written summary · about
chapters (7)
- 0:00Start
- 3:55End-to-end tests validate the behavior the application from the end-user perspective
- 5:30Performance tests validate the speed and responsiveness of the application
- 12:14Page Object Models are widely used for end-to-end testing with Selenium, Webdriver, Protractor, etc.
- 16:41Having a clear, typed Component Harness enables Intellisense / auto-complete in your IDE of choice
- 17:43Component Harness tests are easier to write, easier to read, easier to maintain
- 19:59Component Harnesses can be used in different contexts (end-to-end tests, unit tests) with one single syntax, or
related talks
22mAngular Component Test Harnesses FTW
28mAngular Component Test Harnesses FTW
24mComponentizing end-to-end tests
01h 11mStop Using the Console to Test Components
40mCypress Component Testing - The Disappearance of Mr. Button
15mCypress Component Testing - Lightning talk
30mIntroducing Component Testing with Cypress
01h 11mStop Using the Console to Test Components
