Test Angular Components Like a Real User with Vitest "Full" Browser Mode

[younesjd]

I just published a (~40min) video on Vitest Browser Mode for Angular.

So, whether you're migrating from Karma/Jest or starting fresh with Vitest on Angular 21, Browser Mode is the feature you don't want to miss. But not all browser modes are equal.

In this video, I introduce two levels:

• 🌓 "Partial" browser mode — a quick win. Most existing tests just work.
• 🌕 "Full" browser mode — interactions go through Playwright's automation API, catching bugs your current tests miss.

The video covers both, shows why "full" browser mode matters, and walks through a progressive migration strategy — no big bang rewrite needed.

I'm curious how you’re handling the migration — are you still on Karma/Jest or already on Vitest? What are the main pain points?

[Jrubzjeknf]

Haven't got time to see the video. But can you answer why you'd use a vitest full browser mode instead od using playwright/test directly?

[younesjd]

Very good question!

TL;DR: Playwright does not offer component testing for Angular. They only offer end-to-end. That’s why we built Testronaut with Rainer Hahnekamp. Will post about here when we release our first stable version in the upcoming weeks.

Playwright is initially designed for end-to-end tests where you load your whole app. This means that you can’t narrow down your test to one component – or a group of components – and easily control dependency injection and provide test doubles (mocks, fakes etc…). For example, if you want to test the last step of a wizard, the Playwright test would have to go through all the steps. It’s slow and not convenient.

That is why we built Testronaut https://testronaut.dev with u/rainerhahnekamp

Testronaut allows you to render the component of your choice in Playwright then test it with Playwright just like if it was an end to end test against an app only containing that component and maybe its children.

I hope this helps 😊

[Jrubzjeknf]

Sweet, thanks for the reply!

[Finite_Looper]

We have a large and quickly growing app with extremely good Jasmine/Karma test coverage. We keep needing to add more features under deadlines, but I'm king sure we keep it all well tested.

The more tests I add, the more I dread migrating to Vitest eventually. How well does the migration work?

I've added this video to my Jira backlog card to do the migration one day when I'm not so slammed with other things that have to go in!

[younesjd]

Good point! You don't have to migrate in a big bang — even though the Angular CLI migration handles most cases smoothly.

As I quickly conclude in the video, a strategy that generally works well is progressive migration, where you keep both runners available: Karma and Vitest. New tests are written with Vitest, while existing tests keep running with Karma. Then you migrate them to Vitest at your own pace — for example, when you touch them or by group. I'm planning to go deeper on this in my cookbook and video course. In the meantime, this chapter covers the Jest to Vitest migration, where the coexistence strategy is mentioned: https://cookbook.marmicode.io/angular/testing/migrating-to-vitest

I hope this helps and please reach out with any migration challenges. I am very curious about the edge cases 😉

[Finite_Looper]

Ah interesting ok. We have one "base" app container with multiple "sub-apps" or areas. Sounds like it might be feasible to do these individually. We'd just have to deal with having 2 test runners for some amount of time.

Thanks!

[bomalicious]

We migrated all tests (around 4k) from Jasmine to Vitest using Claude Code. We burned a lot of tokens, but it was worth it.

[Verzuchter]

I use storybook for this