Test we react correctly to any events emitted from child components:

Test any directive that defines if/how child component is rendered (for example, v-if and v-for).

The most important guideline to give is the following: Write clean unit tests if there is actual value in testing a complex piece of logic in isolation to prevent it from breaking in the future Otherwise, try to write your specs as close to the user’s flow as possible

So the question becomes how many tests are enough?

I am a big advocate of having a complete test base and even erring on the side of caution when it comes to quality engineering and software validation but that is not what we’re talking about here. What we’re talking about here are the tests that we write when we’re doing test-first development and I’m proposing that writing those tests from the perspective of specifying the behaviors that we want to create is a highly valuable way of writing tests because it drives us to think at the right level of abstraction for creating behavioral tests and that allow us the freedom to refactor our code without breaking it.

Three tests to prove a small piece of behavior. Although it might seem overkill for such a small feature, these tests are quick to write—that is, once you know how to write them

We mostly write integration tests, by the way—and 20% is not that bad (but can be even better).

We are not testing styles specifically at this time

Integration specs are relied upon to ensure the application functions, but does not ensure pixel-level stylistic perfection.

I should also add that I'm in favor of relying more heavily on integration testing. When you do this, you need to unit test fewer of your simple components and wind up only having to unit test edge cases for components (which can mock all they want).

Often, if you are writing a test that amounts to “it does what it does”, or “it does exactly this, which happens to be duplicated in the application code”, then the test is either unnecessary or too broad.

Here are three rules of thumb I use to determine that something is not worth testing:Will the test have to duplicate exactly the application code? This will make it brittle.Will making assertions in the test duplicate any behavior that is already covered by (and the responsibility of) library code?From an outsider’s perspective, is this detail important, or is it only an internal concern? Can the effect of this internal detail be described using only the component’s public API?