-
Notifications
You must be signed in to change notification settings - Fork 245
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
Stubs rendering default props #945
Comments
Hey John. Where are Snapshots + stubs are difficult to handle - seems like there are varying opinions on what should and should not be rendered. I wonder if we can provide a few different snapshot serializers, so people can choose the snapshot behavior they'd like. 🤔 |
They are defined on the actual "Button" component that I'm stubbing out. These specific props are defined with default values that are being rendered by the snapshot. (In this particular case they are defined in the PrimeVue component library I'm using) I'm assuming that the actual Button component is being evaluated before the stubbing process takes place. |
I ran into another issue which leads me to believe this is the case and the stubbing process should be examined. In this new situation, one of my stubbed components has dependencies which are not accounted for in the context of the test. The test crashes... but it shouldn't matter because the component should be stubbed out. |
What do you mean by "has dependencies"? As in it imports other modules? The stubbing VTU offers is just before the component is rendered; it will still get imported (as well as all its dependencies). Assuming my understanding of your question is correct, if you want to completely and totally stub out a component (and the modules it imports) you could use |
Yeah I think you understood correctly. Your idea to use jest.mock sounds really interesting! I'll give it a go! |
Cool, here is a basic example: https://lmiller1990.github.io/vue-testing-handbook/vue-router.html#workaround-for-large-render-trees-using-mount We should still fix the stubbing bug for <script setup>. |
I'm also experiencing this in https://github.com/posva/vue-router-mock/ where the existing test fails: const wrapper = mount(
{
template: `<router-link to="/">Hello</router-link>`,
},
{ global: { stubs: { RouterLink: true } } }
)
expect(wrapper.html()).toMatchInlineSnapshot(
`"<router-link-stub to=\\"/\\"></router-link-stub>"`
)
Here is a boiled down repro @lmiller1990: it('fails', () => {
const wrapper = mount(
{
template: `<Thing />`,
components: {
Thing: {
props: {
one: {
type: String,
default: 'not-rendered',
},
},
},
},
},
{
global: {
stubs: {
Thing: true,
},
},
}
)
expect(wrapper.html()).toMatchInlineSnapshot(
`"<thing-stub></thing-stub>"`
)
}) This test currently fails at the snapshot because it renders the |
You can define your own way how stubs are created by a plugin ( |
When rendering snapshots, stubbed components are actually being evaluated in order to apply the default props to the element.
For example if my component imports and contains the following code:
And I stub out the
Button
component in my testMy snapshot will render with
<button-stub label="Cancel" icon="pi pi-times" iconpos="left" loading="false" loadingicon="pi pi-spinner pi-spin" disabled="false" class="p-button-text"></button-stub>
iconpos="left"
andloadingicon="pi pi-spinner pi-spin"
should not be rendered.This is annoying for me because whenever I update my
Button
component my snapshots for anything using theButton
component need to be updated. I already have myButton
component covered with its own tests so this is unnecessary.The text was updated successfully, but these errors were encountered: