Open lacolaco opened 1 year ago
If we just want to query the generated DOM with the Testing Library, the within()
function will solve this problem. Rather, I think it is more important to be able to take advantage of RouterTestingHarness while retaining the hiding and intuitive configuration of TestBed that render()
achieves.
Hi @lacolaco sorry, I missed this issue. While reading the introduction I was also thinking about this. But, I'm still not sure how to proceed with it 😅
Do you have any ideas? Or to ask the question differently, what use cases does it solve better than it does currently?
@timdeschryver I don't have yet.
After I wrote this issue, Angular v16 supports router input binding withComponentInputs()
, which allows us to pass data as inputs instead of Router params. Use-cases about component reactivity with router params I imagined are almost resolved by the feature.
I have a use-case for this (or at least for supporting routing). Navigation is a user-action and the primary goal of the Testing-Library framework is that it:
helps you test UI components in a user-centric way.
However, the testing-library offers no utility functions for navigation nor does the Angular Testing Library.
The issue I'm facing is that I want to test a Component that has a \
Angular introduced RouterTestingHarness as a utility for testing a component that depends on the router.
RouterTestingHarness manages a root component to instantiate
<router-outlet>
and returns routed component bynavigateByUrl(url, component)
method. AFAIK, there is a conflict with the testing-library'srender()
approach. The responsibility for instantiating a ComponentFixture must be one or the other.So, I can't suggest a specific solution yet, but I think that testing involving Router can be complex and this is precisely the kind of area that the Testing Library should help with. It would be desirable to provide a means to escape from MockRouter and MockActivatedRoute while still being able to use them with the Testing Library.