Shulou(Shulou.com)06/03 Report--

This article shows you that testing is a waste of time, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Let's explain in detail

As developers, we all know that we should test our code. We should write unit tests, but this is usually the step we skip when we find that we don't have time.

As team members or managers, we all know that testing is necessary, but when the deadline approaches, we tend to reduce testing and focus more on coding.

From this point of view, the testing field seems very tense. We all know that testing is good for us, but once the project is under pressure, we stop testing.

Why are we testing?

Edsger W Dijkstra said: testing can be used to find explicit defects (bug), but cannot show latent software defects (bug).

This means that testing does not guarantee that your software is bug-free, but it does help. We can also put it another way, if we don't test, we can almost guarantee that our software will be bug, unless we are writing something like "hello world!" Such a simple program. But you can test even such a simple program, because once you have entered your code, you will wonder if its output is really "hello world!" .

And this is the test in the form of a class, and that's what we've been doing: manual testing. We write a program, and then start it to verify the results. This may be sufficient for a simple "hello world", but for more complex programs it can lead to a waste of time, which is a manual repetition of a known behavior result set. Isn't that why we invented computers in the first place?

This is not a big problem for "hello world", but when you create a web application, the test scenario is to turn the page ten times, click some buttons, enter a lot of (correct) data into the form and then test certain items, and you can see that automation saves a lot of time. If you can execute the function you want to test directly through the test runner (test runner), instead of having to spend half a minute manually executing that function, you will save a lot of time!

But it also means that we need a little more programming, and more programming means more time and effort. So it will take more time and your project may be completed later.

Maybe not.

Let's create a console application to calculate the two integers of the * common divisor (GCD). There are many ways to solve this problem, but for simplicity, we will

1. Enter two integers

two。 Regardless of the algorithm, calculate the GCD

3. Display output

Let's take a look at the normal development cycle. We usually write a main () function, get two integers, and call a function to calculate the GCD, and then display the result.

test. Entering 2 integers in your console will take some time, which will become quite boring if you need to repeat your code many times. It is also easy to type errors in the console application, causing the program to crash. This means that you have to restart the program, enter two digits, and then verify the results again. Keep in mind that we are talking about a console application that requires only two input values and no clicks (in web applications), which we have seen will take some time.

Then, we will probably want to test some more values that mean restarting the program, enter double digits (correctly), and then test. So even if we see it, we won't do it right away, because it takes too much time. Edge cases will be forgotten and errors will only be found in production!

In addition, when we change something we need to run all the tests again (manually), using a high-risk test that has been forgotten or uses keyboard shortcuts.

There will be no tracking of our testing work. Do not write to the log file throughout the test, unless you add this list of things you do (manually).

Negative feedback loop

Usually, when a project is delayed (for some reason), it is easy to fall into a negative feedback loop. Sometimes we decide to skip writing test code first, which results in the situation as shown in the following figure:

The delay of the project caused us to write more code. So instead of "wasting time" constantly testing the code, keep developing the project. The result is a further decline in code quality, which eventually (sooner or later) leads to rework. Rework usually becomes urgent in the most limited time (some people call this phenomenon "Murphy is an optimist!" ). In fact, rework will not change anything, the project will only be further delayed. Oddly enough, the more code we write, the later our project will be completed. A common response is to get more developers involved in the development of the project, but this only exacerbates the negative feedback loop.

If the project lacks testing, users will usually find a lot of bug in the acceptance and production environment, which will quickly reduce users' trust in the project, resulting in negative feedback. This feedback is passed on to (overworked) developers, causing developers to be "tired". The consequence is that the enthusiasm of the developers decreases and the developers leave their jobs. The project has been further delayed.

Break the negative cycle

I think you have thought of a way to solve this phenomenon. Let's draw a different scene:

We can start with an ideal plan, "the project is completed on time". We develop the code and test it immediately. The test is automated (coding implementation) so that we can easily and effectively execute it. We combine development and testing closely together, and each development test cycle can be executed very quickly. When a development test cycle ends, we are confident that the code quality is high because it has passed the test. And users continue to have a high degree of trust in us because of the decrease in the number of bug found. Even if they find a defect (which is still possible), we can expand our test set to avoid the recurrence of related defects.

If this goes on, rework will no longer be necessary and the project will have to continue.

If our project has been postponed, it will take us some time to adopt this methodology. A freeze on new features may be necessary. Stop developing new code and instead write tests for the most serious (annoying-clear-costly) defects.

It is not feasible to write tests for your complete code base when the project is delayed, just for some of them, don't waste your time. But to keep in mind that other parts also need to write tests. In this case, I will identify the most serious problems (prioritize) and write tests for them. After that, it will be easier to "quickly" modify the code, and it can be guaranteed that it will not make mistakes in the rest of the modification. Automated tests can be performed frequently, reducing the risk of bug recurrence. All right, now we can start to effectively strengthen our project.

These usually require code refactoring to make it testable.

In most projects, the balance between testing and coding is considered. But I hope everyone knows that testing is actually an accelerator of the project, not a waste of time.

The above is that testing is a waste of time. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.