feat: add "How to test passing props" section

[Adrià Fontcuberta]

One of the common frictions in VTU is how to test that given a prop, something happens in the component under testing.

We should explain:

• How to pass in props, and assert the expected behavior (a special case is a prop that triggers some sort of behaviour in created or mounted).
• How to "update" that prop. This might change depending on the final VTU API (related), but we could "officialy" suggest using a Wrapper component for the time being.

[Lachlan Miller]

This is definitely an important section to write, I'm looking forward to what we come up with.

The main case I see for updating a prop is when you have a watch on it. I will investigate what it would take to implement setProps, it may not be difficult. I like the wrapper idea as well.

Are you interested in writing this guide?

[Adrià Fontcuberta]

Sure! In my head is looked like the following:

• I have a simple component that renders a prop
  well, I just write a different test with a different prop value rather than trying to update the prop. Props are part of the public API of a component!
• Okay, but what if my prop being true triggers something on created()?
  Well, here's an example (with possibly an await nextTick() right after mounting?)
• However, I have this other component where the prop – as you mentioned– is being watched, thus writing another test would not help.
  This is where a wrapper/setProps/whatever makes sense.

So this would read as some sort of story telling, but as it would be split in 3, one could just jump to the solution for the issue they are facing.

[Lachlan Miller]

That sounds great. One idea could be some component that takes a foo prop with a default value. If the user does not pass a prop, something can happen in created - just thinking out loud.

Happy to review anything 👍 no rush, I don't think we need to have a full set of docs until we have at had a few alphas.

[Dobromir Hristov]

@afontcu exactly how I imagine it as well. setProps is not added, so it is a viable option for point 3.
People can also pass a ref to test watchers, which is basically what setProps kind of does.

Do you need help with this?

[Adrià Fontcuberta]

Do you need help with this?

by all means! :) I think this would make great content for the "Passing Data" guide section (https://github.com/vuejs/vue-test-utils-next-docs/blob/master/src/guide/passing-data.md).

It would be great if the whole section used the same evolving component, so people can easily jump from snippet to snippet.

[Lachlan Miller]

Makes sense.

I can write something this weekend.

[Dobromir Hristov]

OK then its up to you bud.

[Lachlan Miller]

Thinking of an example that illustrates all three of those use cases is very difficult. I had the idea to use a <Password> component that takes a minLength and maxLength prop where use use the props mounting option change the values and assert the correct error is rendered.

This does lend itself well to an example of changing props - those validations would never change.

Any ideas?

Alternatively we can consider different examples for each case.

[Dobromir Hristov]

I think we are fine with 3 simple components examples. No need to overthink it?

[Adrià Fontcuberta]

Sure! Would've been great to find a valid example for the 3 scenarios (thought about it a bit), but couldn't come up with a solid use case. So I'd just go ahead and keep the three components as simple as possible so there isn't much cognitive overload in a single guide.

[Dobromir Hristov]

Is there something already on this that we can checkout?

[Lachlan Miller]

Not yet, I started something but it's very half baked. Are you interested in picking this up @dobromir-hristov ?

[Dobromir Hristov]

Push to a branch, i can continue