I felt terrible when the writer said the word Edit and Pray because that is how I used to develop; no kidding, I am a front-end developer. I assume that you know what shit things will happen if the damn javascript program was written without tests, especially when you are building a sizeable enterprise-level project. What a nightmare!

Since we already know about the importance of Unit Testing, let's go straight to the main content.

What is Unit Testing?

Well, it is a good question. Let's see it in another way: what isn't Unit Testing?

The writer already told us:

• It is hard to localize the error cause the range of tests is so broad that you don't know which line of code goes wrong.

• It will take forever to finish the test cause you may involve the natural system resources in the test, and it often causes a performance problem.

• It will be so hard to see the final coverage cause when we do the test, we will control the input to see if the output goes right, but if the test is enormous, there would hardly be a proper input to let the test cover the particular code snippet.

So, let's put it together, good tests have these qualities:

• They help us localize problems, and you can figure them out immediately.

• They run fast, like, really fast.

• They are small and often concentrate on only one scenario.

Higher-Level Testing

Kind of like a staging environment in your workflow, I think. Maybe we should call it a staging test?

Anyway, the writer doesn't want to talk about it.

Test Coverings

Let's look at this structure. I am familiar with this structure cause it is a prevalent one. Now we want to test the InvoiceUpdateResponder Method.

Well, With this prevalent structure, Don't ever think about the test. we have at least two problems:

• We won't be able to initiate the DBConnection class as input without setting up an accurate Database, which sucks.

• We won't be able to initiate the InvoiceUpdateServlet class as input cause it will call HTTP request directly, which also sucks.

So the writer makes a better structure to make sure that we can write tests based on it.

In the InvoiceUpdateResponder Method, we don't need to make HTTP requests directly; we only need the list of IDs. As for the Database problem above, we create an interface to break the dependency. So now we can fake the Database to ensure that our tests go well.

There is a question: Why do we still need the InvoiceUpdateServlet in the parameter even though we already have the IDs? I don't know the reason; if you know it, please comment below; thanks.

The Legacy Code Change Algorithm

Although the writer encourages us to break the dependency, we probably will write some ugly codes. So the writer gives us these five algorithms to make our life easier.

Identify change points

Find test points

Break dependencies

Write tests

Make changes and refactor

Don't worry; we will cover all of these algorithms; let's leave this part to the future.