Brainstorming ideas (see notes)

[richardeschloss]

• I like the create-nuxt-app and how it sets up the testing environment. I would like to re-use some of their CLI code to generate the testing environment (in case the dev didn't originally set that up, and if they only wish to quickly set up testing).
• I love vue-test-utils, that will be a dependency of course
• All testing should be set up with a simple command, in my opinion: npm i -D nuxt-test-utils and be ready to go in ~30 sec (goal).
• Pain-points for testing Nuxt plugins are addressed on code I have locally. I would like to clean up that code and commit to here.
• I have a preference for Ava test framework, but I'll try to have examples for the most popular ones: ava, jest.
• Rapid scaffolding would be nice. Since the framework is component-driven, tests should probably be scaffolded on component generation.
• More ideas to come.

[richardeschloss]

Consider supporting some of the ideas presented in nuxt test utils proposal. (To anyone who as already installed nuxt-test-utils, my apologies for neglecting this project. It's still in v0.0.1, and deserves more attention. It will come)

[richardeschloss]

I think it's important to demonstrate (with video) just how fast developers can work when they see the right testing utilities being used. Traditionally, testing is placed on the back burner because of the friction experienced. Think about it: suppose your team contributes 100 components to a project, and then 50 of those just have a minor change, such as file renaming. Same component, just different name. So, it's a total pain the ass to have to change out the names in all of the tests. No one wants to do this kind of maintenance work, not even the TDD proponents like myself.

So, not only is it important to make testing a first-class citizen of the SDLC, it's important to make the component the first class of the project. The utilities should be smart enough to know when components come and go or change (ideal, but not an easy task to pull off).

The main reason so many tests go slow is that many developers fall into this mindset that they need all of their build to be running to test it. The result: super slow tests! Tests that take forever to run. Thus, the right demo videos will show just exactly how fast tests can go when components are tested in isolation. When tests auto-run on save, people will see things working much faster than what they can see on the browser. This sort of quicker feedback should encourage more widespread adoption of testing.

My own personal pitfall is I find myself "repeating myself" with boilerplate code, and I think I can go faster if I stash that code into these utils.

[richardeschloss]

An old but helpful article may be here: https://medium.com/javascript-in-plain-english/nuxt-automated-testing-the-tricky-parts-773f04481dd0?source=your_stories_page---------------------------

Fair note: a lot of my thinking has evolved since writing that, so while the concepts are still the same, the actual code snippets there are out of date (improvements to that have been made since then)