Testing is all about achieve confidence.
How much code coverage do you need?
So that describe in this talk, about Aeron talk about looking for a Sweet Spot.
So, for example, if you are working on in a financial application, you probably want to be more on the right side of the blue line. Because each bug it’s really expensive. Also if you are working in an open-source library, very small and public for a lot of people, also you should fully test your code as well.
If you are working in a regular application, you would like to be in somewhere in the middle of the blue line. And if you are doing an internal tool, maybe you don’t need to do testing at all.
Implementation details are things which users of your code will not typically use, see, or even know about.
Something achieves 100% of coverage force to us to test “Implementation detail”. So what does it’ means?
- Can break when you refactor your application code. False Negative.
- May not fail when you break application code. False Positive.
Kent explain for that reason, he stops using Enzyme, also completely avoid shallow rendering, never use API like
state() , or
When you will find in a situation that you need to expose private function, probably you are testing implementation details.
Also, if your test breaks every time that we refactor our component (without change the actual behavior), the test fails because are testing implementation detail.
Basically, explain, you should have only two kinds of actors that our test should be cover, not three.
- End-User: The real consumer of our component in real life, which will interact with our rendered/mounted component. Basically will observe and interact with the buttons, contents, etc.
- Developer user: The developer that is creating the test for the component using props, to give data into the component.
As a result:
- So our test should typically only see/interact with the props that are passed, and the rendered output.
The Test: that actor we should try to avoid them, it’s a complete waste of time. “ I don’t want tests that are written for their own sake.”
Static code Analysis
- It’s about format testing, like ESLint help a lot about this.
- Flow and Typescript are to eliminate this category of test.
- Semicolon and style stuff should be used for that prettier.
- Should never make an actual network call. You should mock the server response by mocking modules responsible for making the networks calls.
- It’s really good to make integration test because of test a set of functionalities of our app.
This diagram above, it shows how “Static test” it’s cheaper, and then unit test, integration test and an end to end, are more expensive (despite the fact that cypress does a really good job, it tends to be more expensive doing e2e testing than a unit test).
Also, startup a full environment like doing E2E, it’s slow then run Unit testing.
So, as much you a cover your testing Trophy, so doing from the bottom to the top, as much of “confidence coefficient” also goes up.
If you looking for a balance, we could see how Integration testing it’s the balance between cheaper and expensive, and get immediately more confidence too.
It does not say that UT it’s not valuable, he is the point in out, that it’s a good balance and good architecture to focus on integration test than E2E or unit test.