Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RouterTestingHarness: Provide an option to configure the root component #54661

Open
pfeileon opened this issue Feb 29, 2024 · 1 comment
Open
Labels
action: discuss area: router feature Issue that requests a new feature
Milestone

Comments

@pfeileon
Copy link

Which @angular/* package(s) are relevant/related to the feature request?

router

Description

In some integration tests you'd like more control over the boostrapped root component.

Guards on lazy routes, for instance, are initialized before any of the parent components are instantiated. This causes issues when trying to (integration) test (automatic) login scenarios.

Proposed solution

Ideally you'd pass in a higher order component which is composed with the original root component; but since functional components are not a thing that seems like a long shot at best. So you'd probably have to implement your own RouterTestingHarnessRootComponent:

const routerHarness = await RouterTestingHarness.create({
  initialUrl?: string;
  root?: RouterTestingHarnessRootComponent;
);

Alternatives considered

You can manually create a test root component first:

TestBed.createComponent(RootComponent);
routerHarness = await RouterTestingHarness.create();

This works if you re-use this component in your provided routes but it's only a workaround since the component is created twice.

@ngbot ngbot bot added this to the needsTriage milestone Feb 29, 2024
@atscott
Copy link
Contributor

atscott commented Feb 29, 2024

It's a bit more complicated than just allowing a custom fixture. At the very least, that custom fixture would need to have the same @ViewChild(RouterOutlet) outlet. This also wouldn't be capable of covering other scenarios like multiple named outlets at the root.

The RouterTestingHarness won't be able to solve all test scenarios but should be capable of covering the most common use cases. It's really not a large implementation - the file is less than 200 lines, including a whole lot of documentation. I think you might be better off just creating your own harness or sticking with the current method of testing rather than attempting to update the harness to be more flexible in this way.

@atscott atscott added action: discuss feature Issue that requests a new feature labels Feb 29, 2024
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action: discuss area: router feature Issue that requests a new feature
Projects
None yet
Development

No branches or pull requests

3 participants