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

Need to reassign stubbed component with findComponent after update to 2.0.0-rc.10 #810

Closed
freakzlike opened this issue Jul 30, 2021 · 3 comments · Fixed by #813
Closed

Comments

@freakzlike
Copy link
Collaborator

I am currently having the issue, that some of my tests fail after updating from 2.0.0-rc.9 to 2.0.0-rc.10. When manually stubbing a component then I need to reassign the wrapper with findComponent to receive the correct values after making any update (e.g. emits or setProps).

After some checking I created a code snippet to test with. If you run the snippet with 2.0.0-rc.9 the tests passes. If running with 2.0.0-rc.10 the test "should test with stub" fails. In comparision with "should test with stub and reassign" there is only the reassign child = wrapper.findComponent({ name: 'ChildComponent' }) missing which is not necessary when testing without manually stub or with 2.0.0-rc.9.

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

const ChildComponent = defineComponent({
  name: 'ChildComponent',
  props: {
    modelValue: {
      type: String,
      required: true
    }
  },
  template: '<span>{{ modelValue }}</span>'
})

const MainComponent = defineComponent({
  components: { ChildComponent },
  props: {
    modelValue: {
      type: String,
      required: true
    }
  },
  template: '<ChildComponent v-model="modelValue" />'
})

describe('test stub', () => {
  it('should test without stub', async () => {
    const wrapper = mount(MainComponent, {
      props: { modelValue: '1' }
    })

    const child = wrapper.findComponent({ name: 'ChildComponent' })
    expect(child.props('modelValue')).toBe('1')

    await wrapper.setProps({ modelValue: '2' })

    expect(child.props('modelValue')).toBe('2')
  })

  /**
   * Test stub component with reassign wrapper with findComponent
   * Works with rc.9 and rc.10
   */
  it('should test with stub and reassign', async () => {
    const wrapper = mount(MainComponent, {
      props: { modelValue: '1' },
      global: {
        stubs: {
          ChildComponent
        }
      }
    })

    let child = wrapper.findComponent({ name: 'ChildComponent' })
    expect(child.props('modelValue')).toBe('1')

    await wrapper.setProps({ modelValue: '2' })

    child = wrapper.findComponent({ name: 'ChildComponent' })
    expect(child.props('modelValue')).toBe('2')
  })

  /**
   * Test stub component without reassign wrapper with findComponent
   * Works with rc.9. Fails with rc.10
   */
  it('should test with stub', async () => {
    const wrapper = mount(MainComponent, {
      props: { modelValue: '1' },
      global: {
        stubs: {
          ChildComponent
        }
      }
    })

    const child = wrapper.findComponent({ name: 'ChildComponent' })
    expect(child.props('modelValue')).toBe('1')

    await wrapper.setProps({ modelValue: '2' })

    expect(child.props('modelValue')).toBe('2')
  })
})
@cexbrayat
Copy link
Member

Hi @freakzlike thanks for the detailed report

rc.10 included a lot of work around stubs from @xanf

@xanf was this intended or do you think it is a regression?

@lmiller1990
Copy link
Member

lmiller1990 commented Jul 31, 2021

If you pass ChildComponent to components instead of stubs does it work?

As an aside, what exactly is the goal here? What is the use case to test if v-model works with a stubbed component? I understand this is a minimal reproduction, I'm not sure what the real world parallel for this use case is. I am still interesting in finding out if this change was intentional or not.

Hard to say which is "correct", since this is not something you can do in a real app, so I suppose we should match whatever VTU v1 does.

@xanf
Copy link
Collaborator

xanf commented Jul 31, 2021

@freakzlike Thank you for catching that

@lmiller1990 @cexbrayat This was unintended regression, I've created #813 to fix that and explained root cause of the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants