Skip to content

Return nextTick Promise from wrapper interactions #1515

Closed
@tbuteler

Description

@tbuteler

What problem does this feature solve?

We recently updated our Vue test suite to beta 33 from beta 29, and a lot of our tests broke because we were expecting many DOM changes to take effect immediately, when now they happen after nextTick. This is fine: it's well documented and mimics how a component behaves in "real life", so no problems there.

We had to pepper our tests with a lot of await wrapper.vm.$nextTick, and figured we might be able to drop a few lines if we can have the interactions with our wrapper objects return a promise instead of the tests having to create and await them. Normally we would call it after each setData, setProps or trigger call to the wrapper, but I'm sure there are other methods that could benefit from it as well.

Maybe this is not too disruptive, since those methods currently return void, so I'm guessing most workflows would be unaffected. It would just offer an alternative to those who prefer a shorter syntax.

The Vue function is already imported in test-utils/src/wrapper.js, so I ran a quick test and this worked fine:

/**
 * Dispatches a DOM event on wrapper
 */
trigger(type: string, options: Object = {}) {
  // ...

  const event = createDOMEvent(type, options)
  this.element.dispatchEvent(event)

  return Vue.nextTick()
}

What does the proposed API look like?

Taking the example listed in the current documentations for using nextTick:

// Before (would still work as is)
it('button click should increment the count text', async () => {
  expect(wrapper.text()).toContain('0')
  const button = wrapper.find('button')
  button.trigger('click')
  await wrapper.vm.$nextTick()
  expect(wrapper.text()).toContain('1')
})
// After
it('button click should increment the count text', async () => {
  expect(wrapper.text()).toContain('0')
  const button = wrapper.find('button')
  await button.trigger('click')
  expect(wrapper.text()).toContain('1')
})

Doesn't seem like much of a trim, but in our case at least it adds up to quite a few lines.

I'd love to know what you guys think, and thanks for your effort on this library.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions