Named slots' content is not generated for stubbed components via shallowMount

[chriswa]

What problem does this feature solve?

Higher-order components make use of named slots. It's possible to test higher-order components via shallowMount because named slot content can be mocked, but it's not possible to test components which consume higher-order components because their generated named slot output is not available in the stubbed content.

#782 added support for outputting default slot content, but not named slots.

To be clear, an example of a component which needs this support is:

<!-- myComponent.vue -->
<template>
  <HigherOrderComponent foo="bar">
    default slot content
    <template v-slot="header">header slot content</template>
    <template v-slot="footer">footer slot content<HigherOrderComponent foo="waldo"/></template>
  </HigherOrderComponent>
</template>

Currently, this is stubbed out to only:

<higherordercomponent-stub foo="bar">default slot content</higherordercomponent-stub>

The end user experience should be that components which generate named slot content "just work" when testing with shallowMount.

What does the proposed API look like?

The API would not change.

[runarberg]

Related to #1261?

[chriswa]

@runarberg I think this is a different issue. The "old syntax" slots render, but they do not render with any kind of wrapper, so they appear to be in the default slot and it's not possible for a test to confirm whether content was rendered to the correct slot.

[chriswa]

To be clear, to properly test a component, its shallowMount rendering should be something like this:

<higherordercomponent-stub foo="bar">
  default slot content
  <template-stub v-slot="header">header slot content</template-stub>
  <template-stub v-slot="footer">footer slot content<higherordercomponent-stub foo="waldo"/></template-stub>
</higherordercomponent-stub>

Not simply this:

<higherordercomponent-stub foo="bar">
  default slot content
  header slot content
  footer slot content<higherordercomponent-stub foo="waldo"/>
</higherordercomponent-stub>

[jcmillett]

I was hoping #1261 would fix the issue we were having with moving our codebase to the new slot syntax, but that didn't resolve the issue. Moving to the new slot syntax breaks a lot of our existing unit tests.

It looks like this would allow us to use the new syntax while keeping our existing unit tests as-is. Is there a timeline of when this would be available?

[lmiller1990]

I believe the new slot syntax is now supported @jcmillett - this is a differerent issue unique to shallowMount, no?

[lmiller1990]

I have closed the PR that supposedly solved this problem.

We will revisit shallowMount and how it should render things for the Vue 3 integration. At this point, I don't think we will change how shallowMount is working.

I will make a new issue when we revisit shallowMount for v3 integration and invite everyone's input that point.

[danieltian]

For those looking for a solution now, manually stubbing out the component seems to render the child slots:

const wrapper = shallowMount(MyComponent, {
  stubs: { HigherOrderComponent }
}

expect(wrapper.text()).toContain('header slot content');
expect(wrapper.text()).toContain('footer slot content');

[lmiller1990]

This may work but you end up stubbing so much you aren't really testing anything. The best way to test slots is by using mount, you'll get the same behavior as production and avoid writing tests that give you false confidence.

[danieltian]

but you end up stubbing so much

That's the intention. To use OP's example, I'm writing a unit test for myComponent.vue, so I want HigherOrderComponent to be stubbed out. I also want to test that myComponent is sending down the correct template data to HigherOrderComponent.

Right now, the default template is being rendered in the stub with shallowMount, but named templates are not. This doesn't make sense. Manually stubbing out HigherOrderComponent fixes it so that named templates are rendered in the stub as well.

Using mount means that the unit test is no longer a unit test. If myComponent was the root component, by using mount the entire app is instantiated. This is explicitly mentioned in the official docs:

https://vue-test-utils.vuejs.org/guides/common-tips.html

In unit tests, we typically want to focus on the component being tested as an isolated unit and avoid indirectly asserting the behavior of its child components.

In addition, for components that contain many child components, the entire rendered tree can get really big. Repeatedly rendering all child components could slow down our tests.

Vue Test Utils allows you to mount a component without rendering its child components (by stubbing them) with the shallowMount method

[lmiller1990]

Important part:

Vue Test Utils allows you to mount a component without rendering its child components (by stubbing them) with the shallowMount method

At least, this was the intention. To stub the children.

Unit testing a single component might make sense sometimes, but if you are testing with slots, it doesn't make a ton of sense to test it as a single unit - it will never be used a single unit, but with other components and children. Just use mount to test it. Using stubs and shallow is really just making more work for yourself - but each to their own.

We will improve the docs before Vue 3 integration (over the next few weeks). If you are interested, I will add you as a reviewer to a PR that discusses testing slots, since you have an interest in this topic. There is definitely different ways to accomplish the same thing. We should mention both approaches, and their pros and cons. Is this something you'd like to be involve with?

[danieltian]

it will never be used a single unit, but with other components and children. Just use mount to test it.

mount no longer makes it a unit test, it becomes an integration test, and like all integration tests, everything that's instantiated must be set up properly. If like OP I'm testing the root component and I want to verify in a unit test that the header, footer, and body content is being passed to <HigherOrderComponent> properly, using mount means I have to ensure that every descendant component has the data it needs to render properly. This might mean mocking out API endpoints or any other setup needed, just to test the root component. In other words:

<root-component>
  <child-component-1>
    <child-component-2>
      ...
      <child-component-10> <!-- if this does an AJAX call, I have to mock it -->
        <child-component-11> <!-- if this does an AJAX call, I have to mock it -->

child components 10 and 11 are very far removed from the root component, but by using mount, I now have to mock out endpoints that have nothing to do with the root component. It becomes the same problem as instantiating the entire app and setting everything up for that to happen, just to test one thing.

Using stubs and shallow is really just making more work for yourself

shallowMount works exactly as expected, except when it comes to rendering named slots. I believe you're saying that because the slot is rendered in the child and the child is stubbed, so the slot shouldn't be rendered, and that would make sense, except that the default slot is rendered. This is what I mean by it doesn't make sense; why would the default slot get rendered, but not named slots? If stubbed children shouldn't render anything, then why is the default slot getting rendered?

Ultimately, what we need is a way to unit test a component that passes down named slot templates to a stubbed child. It's already possible to check for attributes() and props() passed down to a child using shallowMount, but currently nothing exists for templates, so we have no choice but to check the contents of the child stub. Ideally, there'd be something like wrapper.templates() so that we don't have to rely on the child rendering the slot template, but for now the stubs: { Component } workaround works.