Nuxt Test Utils

[Austio]

What problem does this feature solve?

This feature would make testing ability a first class citizen in Nuxt and it's future iterations.

When running component tests on a nuxt project, there is a fair amount of "extra" stuff that we currently have to shim on top of vue-test-utils in order to add specs around our components.

What does the proposed changes look like?

This is more of a policy change but i'm happy to contribute. Currently when a feature is released, there is little consideration on the ability to test the concepts inside of core external testling libraries like 'vue-test-utils' for unit tests. I would love to help that not be the case any more.

The current recommendation is mostly to run a full request spec by booting your entire nuxt server and then run a spec against that. That is great for tiny projects or when you want to make sure something really works end to end. On large projects though it would take many minutes to boot which would cause devs to skip writing tests in the real world.

A great example of this is the very useful $fetch utility. In order to use this and have component tests on components, we will have to create a custom $fetch that we attach to a vue prototype that we assert around. It would be much better if we could have something like this from the nuxt repo or a sidecar repo (nuxt-test-utils?)

const vm = createNuxtInstance()

createNuxtInstance could take many options such as

• whether it should include the reflected store (something we have written custom code to do and are happy to contribute)
• whether is should include a router
• etc

This would also pave the way for additional hooks so that library authors could provide the ability to hook into this ecosystem in order to attach to the instance in a "mock" way

Nuxt hooks

test:nuxtInstanceMounted test:nuxtInstanceCreated

_{This feature request is available on Nuxt community (#c10775)}

[richardeschloss]

I like the ideas presented here, and I think the issue will get more attention if broken down into smaller manageable issues. If I understand correctly, it sounds like the separate issues are:

1. Create (build) a local nuxt instance, that gets built based on options provided to it (i.e, to include the store, and what module(s) to include. Is it possible that nuxt builder accomplishes this already with it's provided options? This way, it seems like a lot of module tests that use nuxt.build() can continue doing so. Seems like some work has been made here? https://test-utils.nuxtjs.org/usage . I think the key to making testing a first class citizen will be speeding up the setup time (only build nuxt with what the test needs).

2. Mock the $fetch method. I think for the sake of testing, this could just take "url" as an argument and provide a mocked response. The tests would then assert that response was received.

3. Consider renaming module-test-utils to @nuxt/test-utils. I think it'll communicate the message better that those utils aren't just for modules. While I have worked on nuxt-test-utils, I haven't really done a whole lot there (it's been at v0.0.1 forever) and it's tougher for me to stay committed to that project. I'll be happy to submit PRs though from code that I have there if that may help. What I would find particularly useful is having those utils just ready to go after installing nuxt. I think create-nuxt-app already scaffolds some sample tests based on the test framework chosen, but perhaps those sample tests can be simplified with nuxt-utils?

4. Encourage TDD behavior and habits. The TDD is probably avoided by devs who experience friction or slowness when writing tests. It's also human nature to experience "shiny new object syndrome" in web development, where everything else seems 1000x cooler than writing the tests. However, tests that auto fire on save can show people results much faster HMR, and the only way to believe it is by experiencing it (which I don't think enough people realize). I think test scripts are included already in the generated package.json, but if not, consider adding them

[pi0]

Hi @richardeschloss thanks for summary. Indeed the plan is to move module-test-utils into nuxt/test-utils and missing part is generic front testing like mocking $fetch as mentioned. PRs and ideas are more than welcome :)

[msmsimondean]

@pi0 I don't know if any of the stuff in https://github.com/nuxt/nuxt.js/issues/8247 is of help?