Vue Test utils, Testing scoped slot logic within parent context

Question

I have a "parent" component whose sole focus is to implement a custom table component called <VTable>

I would like to test the logic specific to the parent as it is used in the context of various scoped slots on the child table.

the slots are dynamically declared based on properties supplied in the header.
Given:

const headers = [
{ trackBy: 'lastName', sortable: true, width: '85px' },
{ trackBy: 'status', sortable: true, width: '95px' }
]

then the following slots will be explosed in an implementation

<template>
  <div class="Foo">
    <div class="Foo-table">
      <VTable
        :headers="headers"
        :rows="rows"
        :sort="Sort"
        :numeration="getNumeration"
        :loading="isLoading"
        striped
        numerated
        @sort="onSort"
      >
        <template v-slot:row.lastName="{ row, index }">
          ... Custom Implementation ...
        </template>

        <template v-slot:row.status="{ row, index }">
          ... Custom Implementation ...
        </template>
      ...

I am interested in the specific logic within each of the scoped slots.

I can resort to

const wrapper = shallowMount(
          index,
          {
            localVue,
            mocks,
            store: new Vuex.Store(store),
            stubs: {
              'VTable': VTable
            }
          })

and find the raw output via:

const table = wrapper.findComponent({ name: 'VTable' })

table.vnode.elm.innerHTML

but any attempts to use find/findComponent/etc. whether called from wrapper or table are unsuccessful. Is there a way to do this? I imagine matching raw html is discouraged.

Answer 1

The solution in my instance was to stub every other component bar the VTable component with the scoped slots.

const wrapper = mount(
          index,
          {
            localVue,
            mocks,
            store: new Vuex.Store(store),
            stubs: {
              FooComponent: { template: '<div class="FooComponent"></div>' },
              BarComponent: true,
              ...
            }
          })

This approach carries the caveat that tests could become brittle if the component that wasn't stubbed is less generic (that in itself might be an indicator that the component in question requires refactoring)