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

Bug: wrapper.text() is empty for components that only render a slot #1461

Closed
aethr opened this issue Apr 27, 2022 · 2 comments · Fixed by #1463
Closed

Bug: wrapper.text() is empty for components that only render a slot #1461

aethr opened this issue Apr 27, 2022 · 2 comments · Fixed by #1463
Labels
bug Something isn't working

Comments

@aethr
Copy link
Contributor

aethr commented Apr 27, 2022

Describe the bug
When a component's render function only returns the default slot, wrapper.text() for that component is always empty, but wrapper.html() contains all the correct markup.

To Reproduce

The first two tests here succeed, while the last test fails at expect(wrapper.text()).toContain('some text'); even though the same assertion with wrapper.html() passes.

The problem is with the Container component in the final test, which has a render function that only returns the default slot:

    const Container = defineComponent({
      render() {
        return this.$slots.default({});
      },
    });

The return values from Component.render() (first test) and Parent.render() (last test) are almost identical, but VTU treats them very differently.

import { mount } from '@vue/test-utils';
import { defineComponent, h } from 'vue';

describe('Text', () => {
  test('Component text()', () => {
    const Component = defineComponent({
      render: () => [
        h('div', 'some text'),
        h('div', 'other stuff'),
      ],
    });

    const wrapper = mount(Component);

    expect(wrapper.html()).toContain('some text');
    expect(wrapper.text()).toContain('some text'); // succeeds
  });

  test('Slot in div text()', () => {
    const ContainerWithDiv = defineComponent({
      render() {
        return h('div', undefined, this.$slots.default({}));
      },
    });

    const Parent = defineComponent({
      components: { ContainerWithDiv },
      template: `
    <ContainerWithDiv>
      <div>some text</div>
      <div>other stuff</div>
    </ContainerWithDiv>`,
    });

    const wrapper = mount(Parent);

    expect(wrapper.html()).toContain('some text');
    expect(wrapper.text()).toContain('some text'); // succeeds
  });

  test('Slot root text()', () => {
    const Container = defineComponent({
      render() {
        return this.$slots.default({});
      },
    });

    const Parent = defineComponent({
      components: { Container },
      template: `
    <Container>
      <div>some text</div>
      <div>other stuff</div>
    </Container>`,
    });

    const wrapper = mount(Parent);

    expect(wrapper.html()).toContain('some text');
    expect(wrapper.text()).toContain('some text'); // fails here
  });
});

Expected behavior

I would expect wrapper.text() to return something similar to wrapper.html() but without the markup.

Related information:

  • @vue/test-utils version: 2.0.0-rc.21
  • Vue version: 3.2.33
  • node version: 3.2.33
  • npm (or yarn) version: 8.1.0

Additional context

The component causing trouble for us is effectively a headless component. It takes some props, augments them or transforms them, and makes them available via slot props. We use this as the top level component for a bunch of Input components, and in the tests for Input components we like to use wrapper.text() to verify that certain values like labels are present "somewhere" without being too specific.

A workaround is to find an element in the wrapper using wrapper.find or wrapper.get and then test the text() of that, which works successfully.

@aethr aethr added the bug Something isn't working label Apr 27, 2022
@lmiller1990
Copy link
Member

lmiller1990 commented Apr 29, 2022

Thanks for the detailed bug report. I wonder if 711a35f would fix it (just merged, not release yet). Unlikely, but looks like it's around the same area of the code base.

@freakzlike
Copy link
Collaborator

It was reproducible in the VTU unit tests, but I have not yet been able to take a closer look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants