Add ability to write tests inside of a <test> block inside of SFCs

[xryanmason]

Feature Description

I would like the ability to write unit tests inside of a custom block <test> inside of the Vue file that is under test.

Problem

Having a file and subsequent test file creates noise in the project directory. Changing a file in a way that changes the tests means there are two files to update, rather than possibly having all of the changes in one file, which makes for noisy commits.

Expected behaviour

Using the example found here https://vue-test-utils.vuejs.org/guides/#getting-started, you could do the following:

// MessageComponent.vue
<template>
<p>{{msg}}</p>
</template>

<script setup lang='ts'>
defineProps<{msg: string}>()
</script>

<test>
// Import the `mount()` method from Vue Test Utils
import { mount } from '@vue/test-utils'
import MessageComponent from '@/components/MessageComponent.vue' // reimport?

test('displays message', () => {
  // mount() returns a wrapped Vue component we can interact with
  const wrapper = mount(MessageComponent, {
    propsData: {
      msg: 'Hello world'
    }
  })

  // Assert the rendered text of the component
  expect(wrapper.text()).toContain('Hello world')
})
</test>

I'm not sure exactly what the interaction would be like, such as when these blocks would run. I think it'd be nice to have them run in watch mode if the project is running in development mode and then run all of the blocks during a build.

Here are a couple examples of other Vue related projects utilizing custom blocks: https://kazupon.github.io/vue-i18n/guide/sfc.html#basic-usage https://github.com/ktsn/vue-route-generator#route-custom-block

I think this is possible using https://vue-loader.vuejs.org/guide/custom-blocks.html#custom-blocks and/or https://vitejs.dev/guide/migration.html#custom-blocks-transforms, but that starts to get into things that are beyond my expertise.

As an example, Rust puts tests alongside the code: https://doc.rust-lang.org/book/ch11-03-test-organization.html.

Alternatives

One alternative to implementing this as a part of vue-test-utils would be to extend it somehow as a part of a separate project. Another alternative solution could be to continue making separate test files and using the library as it is intended now.

[vincentole]

I like the idea. It reminds me of unit tests in Rust. Another advantage could be that tests don't feel like an extra layer to add on top, but more like an integral part of software development and its workflow.

[uptownhr]

not that vue isn't already leading in the dx department but this would really make it standout of the rest.