VTU-next renders additional markup

[afontcu]

Hi folks! 👋

When trying to port Vue Testing Lib to Vue 3 (and thus vtu-next), I've encountered several issues regarding additional markup rendered by vtu-next.

Some context: Vue Testing Lib provides container and baseElement keys, to help testing scenarios where a div is not a valid DOM wrapper element (imagine a table with rows and columns). I first attempted to leverage attachTo (source), but couldn't prevent snapshots from breaking. I'm not that concerned about snapshots per se, but rather the implications of wrapping every rendered component with an additional div with custom attributes:

I'm not entirely sure we need to mount a div with id="app" – looks like one of the first iterations we did when started working with vtu-next, but I'd say it could go now: https://github.com/vuejs/vue-test-utils-next/blob/master/src/mount.ts#L196-L197

Could we remove the additional markup? This markup will likely impact on any snapshot-based testing done with VTU, and also tools that traverse (poorly, I grant you that 😉) the DOM.

Thanks!

[lmiller1990]

Hm, Vue needs something to mount on, right? Does testing-library use attachTo by default?

I agree we probably do not need the id.

[afontcu]

Hm, Vue needs something to mount on, right? Does testing-library use attachTo by default?

I've tried several combinations of attaching to the container, the baseElement, or a totally unrelated element, without success. Until now (Vue 2), we attach to the container, which makes total sense.

Now, if I do something like the following, tests pass:

const wrapper = mount(Component, { attachTo: container }) 
// here, container is the same thing it was in Vue Testing Lib for Vue 2

function unwrap(node) {
  node.replaceWith(...node.childNodes)
}

unwrap(wrapper.parentElement) // this removes the additional "data-v-app" div node

but still feels a bit hacky?

[lmiller1990]

One difference is that Vue 2 did not have top level fragments; Vue 3 does. I think this is why we have the top level node (maybe).

I think a little hacky is fine, many things in VTU (setProps, all the slots stuff, stubs...) are a little hacky since we are doing some strange things you wouldn't normally do in a real app.

Another potential solution would be solving this in the snapshot serializer. Maybe we should include a serializer with VTU, since it seems important to some people (see #213)

[lmiller1990]

Is this still an issue? Seems you have a fix in testing lib - and #225 removes the useless id.

[afontcu]

Not an issue anymore, I decided to unwrap the wrapper element (source) so the snapshots remain as they were :) Closing this up!