Why We need Front End Test_why do we need test-CSDN博客

本文链接：https://blog.csdn.net/magicxin031/article/details/52817210

First of all, let’s begin this question.

Why do we need test?

Let’s take a look at Kent Beck’s speech Ease at Work at Agile Singapore 2013 Confluence.
In his speech, he addressed these questions.

Why are programmers so often ill at ease with themselves?
Difficulty, great effort, or hard work.
Worry, pain.
What can we do to become comfortable in our own skins?
Writing Test to ensure that what we code does what it’s supposed to do.

Test Benifits

Tests aim to:

Verify functionality
Verify bug fix
Verify browser/device compability
The benefit of writing test is just simple, CONFIDENCE.
Test cases are just like your life insurance, with this insurance, you’ll have confidence when you do code re-factoring, bug fix etcs.

And as times goes by, when the number of test cases grows, it can increase

Work Efficiency (Increase extendability/maintainbility)
Less Regression
Fun of Coding
And for those headache listed above:
Worry, pain?
Gone, I have the test cases, I have the confidence, coding is fun!
Difficulty, great effort, or hard work?
Gone, with test case, code is easy to maintain/extend/re-factoring, less regression, life would be much easier.

That’s the reason why we need test.

Furthurmore

Why do we need TDD?

Here’s three rules of TDD from Uncle Bob

You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Most programmers, when they heard these three rules, they would say.

This is stupid.
It’s going to slow me down, it’s a waste of time and effort, It will keep me from thinking, it will keep me from designing, it will just break my flow.

However, think about what would happen if you walked in a room full of people working this way. Pick any random person at any random time.
A minute ago, all their code worked.
A minute ago, all their code worked.
A minute ago, all their code worked.
And it doesn’t matter who you pick, and it doesn’t matter when you pick. A minute ago all their code worked!

TDD Benifits

Work Efficiency
If all your code works every minute, how often will you use a debugger?
And if you aren’t debugging very much, how much time will you be saving?
How much time do you spend debugging now?
How much time do you spend fixing bugs once you’ve debugged them?
Confidence
Why don’t we clean up code that we know is messy? We’re afraid we’ll break it. But if we have the tests, we can be reasonably sure that the code is not broken, or that we’ll detect the breakage immediately.
If we have the tests we become fearless about making changes.
If we see messy code, or an unclean structure, we can clean it without fear.
Readbility(Tests are documents, examples)
If you want to know how to call a certain API, there is a test that does it.
If you want to know how to create a certain object, there is a test that does it.
Anything you want to know about the existing system, there is a test that demonstrates it.
The tests are like little design documents, little coding examples, that describe how the system works and how to use it. hey are the most useful part of the documentation. They are the living examples of how to use the code. They are design documents that are hideously detailed, utterly unambiguous, so formal that they execute, and they cannot get out of sync with the production code.T
Decoupling
When you follow the three rules of TDD, all your code will be testable by definition! And another word for “testable” is “decoupled”. In order to test a module in isolation, you must decouple it. So TDD forces you to decouple modules. Indeed, if you follow the three rules, you will find yourself doing much more decoupling than you may be used to. This forces you to create better, less coupled, designs.
Tests grows, quality grows.
But the benefit goes far beyond that. If you work this way, then every hour you are producing several tests. Every day dozens of tests. Every month hundreds of tests. Over the course of a year you will write thousands of tests. You can keep all these tests and run them any time you like! When would you run them? All the time! Any time you made any kind of change at all!