Interview question
How do you test Angular routes, guards, and resolvers?
Uses a real route configuration and RouterTestingHarness to verify URLs, rendered components, redirects, guards, and failures.
TL;DR
I provide the routes under test, create a RouterTestingHarness, and navigate to a real URL. Then I assert both the final URL and the routed component or visible state. For a guard or resolver I cover the allowed path, redirect or rejection path, and relevant error behavior.
Angular Router, RouterTestingHarness, guards, resolvers, route parameters, redirects, and navigation state.
Core answer first, then checkpoints toward a stronger answer.
Start here. This is the direct spoken answer to practice first.
Router tests are strongest when they exercise real navigation through a small route configuration rather than mocking router internals.
I provide the routes under test, create a RouterTestingHarness, and navigate to a real URL. Then I assert both the final URL and the routed component or visible state. For a guard or resolver I cover the allowed path, redirect or rejection path, and relevant error behavior.
Optional upgrade with examples, trade-offs, and sharper phrasing.
I do not mock the Router because that can miss matching, parameter, outlet, and redirect behavior. The test uses controlled authentication or data dependencies while leaving Angular navigation real. Route parameters and query parameters are varied through URLs, not by mutating ActivatedRoute internals. Named outlets or unusual host layouts may still need a custom host component rather than the harness alone.
Use these to catch weak phrasing, shallow reasoning, and risky claims.
Optional deeper angle for production judgment and nuance.
I separate client navigation convenience from server authorization: a passing guard test does not prove the API is protected. Resolver tests include slow or failing work and make the intended navigation UX explicit. Rapid navigations can be tested to ensure stale resolved data does not win. A small routed integration suite should catch configuration mistakes while end-to-end tests retain a few direct-entry and browser-history journeys.
Quick interviewer prompts inside this drill.
Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.
Move to the linked follow-up, next path step, prerequisite, or deeper variant.
A manually linked drill from the content graph.
Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.
Help improve the interview library.
Say thanks with a standalone, one-time $5 contribution. No account required.