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

Allow use of components within Wrapper for unit tests #7476

Open
cnotv opened this issue Nov 17, 2022 · 2 comments
Open

Allow use of components within Wrapper for unit tests #7476

cnotv opened this issue Nov 17, 2022 · 2 comments
Assignees
Labels
area/typescript area/unit-test Issues involving need, configuration or changes of unit test kind/tech-debt Technical debt QA/None
Milestone

Comments

@cnotv
Copy link
Contributor

cnotv commented Nov 17, 2022

Description

Change configuration to avoid manual cast of Wrapper<YourComponent> to access wrapper.vm.

Context

Currently if a developer needs to access to a wrapper.vm to get computed or data values or other component properties, it's necessary cast manually the component type to it. This however also causes issues on build and we are forced to use the following code:

const wrapper = shallowMount(YourComponent as unknown as ExtendedVue<Vue, {}, {}, {}, DefaultProps>, {

This may require the use of a custom tsconfig as defined in the docs.

@cnotv cnotv added kind/tech-debt Technical debt area/unit-test Issues involving need, configuration or changes of unit test labels Nov 17, 2022
@cnotv cnotv self-assigned this Nov 17, 2022
@catherineluse
Copy link
Contributor

It would be nice if there was a reusable, generic translation wrapper that could be used for all Rancher components that get moved into the component library if they also have text that needs translation.

@cnotv
Copy link
Contributor Author

cnotv commented Nov 21, 2022

@catherineluse I have already added the global variable and the directive, but unfortunately the translation is a getter from the state and we should not add globally the state for each test. If we do so, it would include also basic components as buttons and functions from the utilities.
Furthermore, in each case where we mock the state, it will be required to rewrite the i18n getter as well.

This is another case where faulty architecture choices could be easily identified by writing tests :)

I would rather suggest to replace that logic in somehow.

PS: This issue is meant to extend the styling of the component, so even if we could, it would require an issue on its own.

@cnotv cnotv removed the priority/2 label May 22, 2023
@cnotv cnotv added this to the v2.7.next4 milestone May 22, 2023
@cnotv cnotv added the QA/None label May 22, 2023
@nwmac nwmac modified the milestones: v2.8.0, v2.8.next1 Aug 15, 2023
@nwmac nwmac modified the milestones: v2.8.next1, v2.8.next2 Nov 17, 2023
@nwmac nwmac modified the milestones: v2.8.next2, v2.10.0 Feb 27, 2024
@nwmac nwmac modified the milestones: v2.10.0, v2.11.0 Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/typescript area/unit-test Issues involving need, configuration or changes of unit test kind/tech-debt Technical debt QA/None
Projects
None yet
Development

No branches or pull requests

4 participants