How to Use Happo with Angular Component Tests

Use Angular component tests to verify behavior and the rendered DOM, then use Happo’s Storybook integration as a separate visual-regression check. The available documentation supports capturing Storybook stories with Happo; it does not establish a direct Happo adapter for Angular TestBed tests.

This separation gives each check a clear job: Angular assertions catch logic and interaction failures, while screenshot comparisons help reveal changes to layout, spacing, typography, and responsive appearance. Angular’s guidance explains that a component test should check that a component’s class and template work together as intended (Angular component testing basics).

1. Check your Angular test setup

Before changing test commands, inspect the project’s Angular version and angular.json. Angular’s current testing overview says new Angular CLI projects use Vitest and jsdom by default, and that ng test runs the configured test target. Karma remains supported for existing projects. Do not assume a runner from the age of the project or from a generic tutorial (Angular testing overview).

ng version

Then inspect the project’s test target in angular.json and its test-related dependencies and scripts in package.json. Keep the configured runner unless you have a separate reason to migrate it. The examples below show the shape of an Angular component test, not a claim about a particular project’s exact runner configuration.

2. Keep behavioral checks in Angular component tests

Use Angular’s TestBed to create the component and inspect its rendered DOM. Assert outcomes a user or another part of the application depends on: visible text, disabled state, emitted events, and how the component responds to input. Keep these checks focused on behavior rather than using screenshots as a substitute for assertions.

Here is a small illustrative example. Adapt the component name, imports, and event API to your application:

import { TestBed } from '@angular/core/testing';
import { SaveButtonComponent } from './save-button.component';

describe('SaveButtonComponent', () => {
  it('shows the saving state and disables the button', async () => {
    await TestBed.configureTestingModule({
      imports: [SaveButtonComponent],
    }).compileComponents();

    const fixture = TestBed.createComponent(SaveButtonComponent);
    fixture.componentRef.setInput('saving', true);
    fixture.detectChanges();

    const button: HTMLButtonElement | null =
      fixture.nativeElement.querySelector('button');

    expect(button).not.toBeNull();
    expect(button?.textContent).toContain('Saving');
    expect(button?.disabled).toBe(true);
  });
});

This snippet assumes a standalone component with a saving input and a button whose label includes “Saving” while that input is true. If your component uses a host fixture, providers, or asynchronous data, configure those dependencies in the test according to the component’s actual setup. Run the project’s configured test target, commonly with ng test.

3. Make representative states available as Storybook stories

Happo’s documented component-oriented route is to render stories and capture them through its Storybook screenshot testing integration. Create stories for the meaningful states reviewers need to see. Depending on the component, that could include a default state, loading, error, disabled, or expanded state. These are practical examples; choose states that exist in your UI rather than creating artificial variants for screenshot coverage.

Give stories stable inputs and data. A story should render the same intended state on each run so a visual difference is useful to review. If a state depends on an interaction, use the interaction approach supported by your Storybook and Happo setup to reach it before capture. Happo describes interaction-driven screenshots as a capability of its Storybook integration (Happo Storybook screenshot testing).

4. Configure Happo’s Storybook integration

Configure Happo according to its current Storybook integration documentation and the versions used by your project. The sources reviewed for this guide do not establish a current Angular-specific package command, compatible version matrix, or direct integration with Angular TestBed. Happo’s repository points readers to current documentation for comprehensive instructions, so use those instructions for the exact install command, configuration keys, and CI command rather than copying unverified package names (Happo repository, Storybook integration guide).

At a workflow level, the integration needs to know which Storybook content to capture and how to publish or compare captures in the project’s Happo workflow. Keep secrets or access tokens in your CI secret store if the current integration requires them; do not commit credentials to the repository. Confirm the setup against Happo’s current documentation when versions or configuration options change.

5. Run visual checks in CI and review diffs

1. Run the Angular component tests using the project’s configured test target.
2. Run the project’s Storybook build or serving step as required by the current Happo integration.
3. Run Happo’s documented Storybook capture workflow in CI.
4. Review the resulting comparison for each changed story and viewport. Treat a diff as a signal to inspect, not automatic proof of a defect.
5. Accept or update the visual baseline only after confirming that the new appearance is intended.

Happo describes browser and viewport coverage, CI review links, and side-by-side, diff, and swipe comparison views. It also describes tolerance settings intended to reduce insignificant image noise. These are vendor-described capabilities; configure the actual browsers, viewports, review process, and tolerance using Happo’s current documentation (Happo Storybook screenshot testing).

Keep the scope understandable: run behavioral tests for logic and interactions, and capture the Storybook states that are important enough to review visually. Capturing every possible combination of inputs can make reviews harder without improving coverage meaningfully.

6. Accessibility checks are an additional signal

Happo advertises an option to include accessibility regression checks with screenshot runs. If you use it, treat those results as an additional check alongside Angular tests and your accessibility review process. It does not replace functional tests, keyboard and assistive-technology evaluation, or a complete accessibility audit (Happo Storybook screenshot testing).

7. Common problems and fixes

Symptom	Likely cause	What to check or do
A Happo setup does not run inside a TestBed test	The documented route is Happo’s Storybook integration; a direct Angular test adapter is not established by the sources used here.	Expose the component state as a Storybook story and configure Happo’s Storybook workflow using its current documentation.
ng test behaves differently from a tutorial	The project may use a different Angular version or configured runner. New CLI projects currently use Vitest and jsdom by default; existing Karma projects remain supported.	Check ng version, angular.json, and the project scripts. Follow the configuration already present in the repository.
A component test cannot find an element or sees stale content	The fixture may not have been detected after inputs changed, or the expected selector and component state may not match.	Set inputs before assertions, call fixture.detectChanges(), and verify the actual template and selector.
A visual capture shows the wrong component state	The story may not provide the intended inputs, data, or interaction sequence.	Make the story state explicit and deterministic; use the integration’s documented interaction mechanism when a control must be activated.
Visual diffs appear on repeated runs	Rendered content or environment may vary, or the configured comparison tolerance may be too strict for the project’s capture conditions.	Check dynamic data, fonts, animation, and the configured viewport and browser. Review Happo’s current tolerance options and avoid hiding meaningful changes with overly broad tolerance.
There is no review result or CI link	The CI workflow may be missing a required credential, publishing step, or documented integration command.	Compare the workflow with Happo’s current CI instructions and confirm required secrets are present without printing them in logs.

8. Performance, reliability, and cost considerations

Visual capture adds browser rendering work to the CI workflow, so start with the states and viewport coverage that protect important UI. A larger matrix of stories, browsers, and viewport sizes means more captures and more review surface. The sources reviewed do not provide reliable run-time benchmarks or pricing details for this specific Angular workflow, so check Happo’s current product information for costs and plan limits.

For reliable comparisons, make stories deterministic: avoid changing timestamps, random values, unstable remote data, and animations that can capture at different frames. Keep behavioral and visual failures distinguishable in CI output, and review changes before updating baselines. These are workflow practices, not vendor performance guarantees.

Or skip the browser setup

If you need screenshots of live web pages rather than component-story visual regression, ScreenshotNeo provides a screenshot API and MCP server. It accepts one GET request and can return PNG, JPEG, WebP, or PDF. It removes cookie and consent banners from 60+ known platforms, along with newsletter popups and chat widgets, before capture; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers.

For example, this cURL request captures a web page. See the ScreenshotNeo API documentation for parameters and options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

The same request in Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

And in Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

Replace YOUR_API_KEY with your key and the URL with the page you want. The Node example uses Bun’s file-writing API; in Node.js, write the returned buffer with node:fs/promises, for example await writeFile('shot.webp', Buffer.from(await res.arrayBuffer())) after importing writeFile.

ScreenshotNeo also has an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. It offers 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000 screenshots. Sign up free for 1,000 screenshots a month, with no card required.

FAQ

Does Happo replace Angular component tests?

No. Keep Angular tests for component behavior and use visual comparisons to review rendered appearance.

Can I use Happo without Storybook?

The sources for this guide establish Happo’s Storybook integration as the supported component-oriented approach. Check Happo’s current documentation for other supported workflows.

Should every component state get a screenshot?

Capture the states whose appearance matters to users or reviewers. There is no need to duplicate every behavioral assertion as a visual snapshot.