-
Notifications
You must be signed in to change notification settings - Fork 27k
feat(core): add option to infer the tag names of components in tests #62283
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
reviewed-for: fw-general, public-api
| // Note: injecting the renderer before accessing the definition appears to be load-bearing. | ||
| const testComponentRenderer = this.inject(TestComponentRenderer); | ||
| const componentDef: ComponentDef<T> = (type as any).ɵcmp; | ||
| const rootElId = `root${_nextRootElementId++}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional nit: It'd be nice to have a comment for the next two lines explaining what this is doing.
devversion
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Reviewed-for: public-api
Exposes the code that we use to infer the tag name of a component as a private export so that we can use it in `TestBed`.
ba6cba3 to
3f210b0
Compare
|
I've reworked this PR with the following changes:
|
Currently when testing a component using `TestBed.createComponent`, we always create the component as a `div` which isn't aligned with the runtime. The runtime tries to parse out the tag name from the first selector in `@Component` and only falls back to `div` if there isn't one. This behavior difference can cause components to not behave like they would in production which reduces the usefulness of the tests. These changes add the `inferTagName` option to `TestBed.createComponent` and `TestBed.configureTestingModule` that allows apps to opt into inferring the tag name from the selector in the same way as the runtime. Currently the new option is set to `false`, but we intend to change it to `true` in a future version.
3f210b0 to
4458318
Compare
|
This PR was merged into the repository by commit cec91c0. The changes were merged into the following branches: main |
…62283) Currently when testing a component using `TestBed.createComponent`, we always create the component as a `div` which isn't aligned with the runtime. The runtime tries to parse out the tag name from the first selector in `@Component` and only falls back to `div` if there isn't one. This behavior difference can cause components to not behave like they would in production which reduces the usefulness of the tests. These changes add the `inferTagName` option to `TestBed.createComponent` and `TestBed.configureTestingModule` that allows apps to opt into inferring the tag name from the selector in the same way as the runtime. Currently the new option is set to `false`, but we intend to change it to `true` in a future version. PR Close #62283
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently when testing a component using
TestBed.createComponent, we always create the component as adivwhich isn't aligned with the runtime. The runtime tries to parse out the tag name from the first selector in@Componentand only falls back todivif there isn't one. This behavior difference can cause components to not behave like they would in production which reduces the usefulness of the tests.These changes add the
inferTagNameoption toTestBed.createComponentandTestBed.configureTestingModulethat allows apps to opt into inferring the tag name from the selector in the same way as the runtime. Currently the new option is set tofalse, but we intend to change it totruein a future version.