Helpers: Suspense (and others?)

[lmiller1990]

#105 had some great discussion around helpers - the example raised there was for components with async setup functions (used in <Suspense>). Testing those alone won't work, since if you have a async setup, Vue expected a <Suspense> wrapper.

We could provide a helper (this works)

  test('uses a helper to mount a component with async setup', async () => {
    const Comp = defineComponent({
      async setup() {
        return () => h('div', 'Async Setup')
      }
    })

    const mountSuspense = async (component: new () => ComponentPublicInstance, options) => {
      const wrapper = mount(defineComponent({
        render() {
          return h(Suspense, null, {
            default: h(component),
            fallback: h('div', 'fallback')
          })
        }
      })
      ...options)
      await flushPromises()
      return wrapper
    }

    const wrapper = mountSuspense(Comp)
    console.log(wrapper.html()) //=> <div>Async Setup</div>
  })

Some thoughts:

• we call flushPromises for the user. Any possible side-effects/unexpected behavior?
• does this belong in this library? Or should we mention in the docs and let users write their own?
• this sets a precedent. One we have one helper, it may be expected others are included. This is not a bad thing, just something to keep in mind.
• do we also then need a shallowMountSuspense? Someone will almost certainly ask for this.
  • if we drop shallowMount as a stand-alone function (which I think we should) and instead have a shallow: true mounting option, this would not be a problem.

[dobromir-hristov]

I was thinking about such helpers too. It is super convenient to have them at your disposal, officially. I also made a similar one for testing stub scoped and named slots.

Maybe we can add all of these to the vtu-extended package we all have been mentioning here and there :D

[lmiller1990]

We could just include them in core. If people will basically install the package every time, why not? Kind of like flush-promises - it's in basically every VTU project ever, it almost feels silly not to include it.

Can you share your helpers here?

[dobromir-hristov]

dhristov/renderSlots-config...feature/stub-slot-utility

[lmiller1990]

Should work for named slots too, right?

Would this help with #2

I am starting to link the idea of including helpers - if we are going to mention them in the guide, we may as well.

• suspense
• slots
• anything else come to mind?

[dobromir-hristov]

This works for any type of slot, but its only to generate a minimal stub, that renders and provides just enough for you to test your slot content.

It will not help with testing slots properly on the mounted component. That is what I will be doing next day or so. I have started a branch locally with cases :)

I agree, we will have some edge cases that may need some some helpers :)

[lmiller1990]

Great, sounds good. I will work on my suspense helper a bit too.

[dobromir-hristov]

I wonder, how are we going to test suspense content? Finding things inside Suspense, while its loading/errored? I could not make findComponent work, I did not test if find managed to find something.

[lmiller1990]

Seems to work with find. No reason why it wouldn't - you just need flush-promises to make the async setup resolve. Is this what you mean?

That's what I am using the tests/features directory for - just testing various "real world" scenarios that are not specific to any method in VTU. I think we can add Vuetify etc here, too.

[dobromir-hristov]

So while writing the ScopesSlots PR I realized this is a pretty nifty way of testing scoped slot params. Deff one I would have loved to have available, a while back.

I think its a great addition to the utilities.

      const assertScopedSlotData = () => {
        let assertion = ref(null)
        const slot = (params) => {
          assertion.value = params
          return ''
        }
        return [assertion, slot]
      }

      const [params, slot] = assertScopedSlotData()

      const wrapper = mount(ComponentWithSlots, {
        slots: {
          scoped: slot,
        }
      })

      expect(params.value).toEqual({
        boolean: true,
        string: 'string',
        object: { foo: 'foo' }
      })

[lmiller1990]

Interesting!

The more I think about it, the more I like the idea of including these utilities. Let's do it.

[lmiller1990]

Should assertScopedSlotData return an object you destructure? Either way is fine - just an idea.

Also, how does assertScopedSlotData get a reference to the current component/wrapper? Do you use it like wrapper.assertScopedSlotData?

[dobromir-hristov]

So how I invisioned using it was as just an external function, that you use as I have shown in the example:

const [namedParams, named] = assertScopedSlotData()
const [defaultParams, default] = assertScopedSlotData()

const wrapper = mount(Comp, { slots: { named, default } })

expect(namedParams).toEqual({})
expect(defaultParams).toEqual({})

This way I think its much easier to name the exported objects, then to destructure and object and re-assign names. But then again, in most cases you test only one slot at a time.... But overall I did not intend this to be in the wrapper as it would have to attach special hidden properties to the instance, which we dont want :) and augment the slot, which I did not want :)

[lmiller1990]

Oh, I see. I was confused by returning return [assertion, slot] but then renaming the first variable to params when you call the function.

This is very cool - what an interesting way to use Vue's reactivity. I am starting to see this decoupled reactivity is actually a huge improvement to Vue overall.

Don't have a strong opinion for/against including this. I personally would still make my assertions against the DOM as opposed the the props the slot receives... this still seems like a fancy way to test an implementation detail (what props are passed) instead of a behavior (what the component actually does with the props).

That said, I think you encounter much more complex uses of slots in your day to day usage - would this make an improvement to the code-bases you work on? Do you think other people would also find this useful? If you think so, I don't have a strong opinion against including this - people who want to use it can, people who don't need not.