Angular Academy · Lesson

Testing Inputs, Outputs, and DOM

Assert on rendered output and events.

Testing Inputs, Outputs, and DOM is a free Angular Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Angular Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Testing the Component Contract

Components communicate through inputs (data in), outputs (events out), and the rendered DOM. Good component tests drive these three surfaces and verify the visible result, not internal implementation details.

Setting an Input

Assign to the component instance's input property, then call detectChanges() to re-render. With signal inputs you set via fixture.componentRef.setInput().

fixture.componentInstance.label = 'Save';
fixture.detectChanges();
// signal inputs:
fixture.componentRef.setInput('label', 'Save');
fixture.detectChanges();

Reading the DOM with querySelector

Use fixture.nativeElement.querySelector() to find rendered elements and assert their text or attributes.

fixture.componentRef.setInput('label', 'Save');
fixture.detectChanges();
const btn = fixture.nativeElement.querySelector('button');
expect(btn.textContent.trim()).toBe('Save');

DebugElement and By.css

fixture.debugElement.query(By.css(...)) returns a DebugElement wrapper. Its .nativeElement is the DOM node, and you get richer queries that survive across platforms.

import { By } from '@angular/platform-browser';

const de = fixture.debugElement.query(By.css('.title'));
expect(de.nativeElement.textContent).toContain('Hello');

queryAll for Lists

For repeated elements (e.g. an @for loop) use queryAll to get every match and check the count.

const items = fixture.debugElement.queryAll(By.css('li'));
expect(items.length).toBe(3);
expect(items[0].nativeElement.textContent).toContain('First');

Simulating a Click

Trigger DOM events to test interaction. Use triggerEventHandler on a DebugElement, or call native .click(), then detectChanges().

const btn = fixture.debugElement.query(By.css('button'));
btn.triggerEventHandler('click');
fixture.detectChanges();
expect(fixture.componentInstance.count).toBe(1);

Testing an Output Event

Subscribe to the component's output (an EventEmitter or output signal) before triggering the action that should emit it.

let emitted: string | undefined;
fixture.componentInstance.saved.subscribe((v: string) => (emitted = v));
fixture.debugElement.query(By.css('button')).triggerEventHandler('click');
expect(emitted).toBe('done');

Asserting on Attributes and Classes

You can verify conditional classes and attributes that depend on inputs.

fixture.componentRef.setInput('active', true);
fixture.detectChanges();
const el = fixture.nativeElement.querySelector('.tab');
expect(el.classList.contains('active')).toBe(true);

Updating Form Inputs

To test text fields, set the input value and dispatch an input event so Angular bindings update.

const input = fixture.nativeElement.querySelector('input');
input.value = 'hello';
input.dispatchEvent(new Event('input'));
fixture.detectChanges();
expect(fixture.componentInstance.text).toBe('hello');

Why detectChanges After Every Change

Zone-based and zoneless tests both require an explicit detectChanges() after you mutate state, because the test runs outside Angular's automatic tick. Forgetting it is the #1 cause of "my assertion sees stale DOM".

Test Behavior, Not Internals

Prefer asserting on rendered output and emitted events over private fields. This keeps tests resilient: refactoring internals should not break a test that still produces the same user-visible behavior.

Quick Check

Which API gives you a DebugElement?

Recap

You drove inputs via setInput, read the DOM with querySelector and By.css, captured outputs by subscribing, and simulated clicks/input events. Always detectChanges() after a change, and assert on user-visible behavior.

Frequently asked questions

Is the “Testing Inputs, Outputs, and DOM” lesson free?

Yes — the full text of “Testing Inputs, Outputs, and DOM” is free to read here on the web, and the Angular Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Angular Academy course, upgrade to CoddyKit PRO.

What will I learn in “Testing Inputs, Outputs, and DOM”?

Assert on rendered output and events. You practise Angular Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Angular Academy?

No prior experience is required. Angular Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Testing Inputs, Outputs, and DOM” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Angular Academy lesson?

Yes. Every Angular Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Angular Academy