Automated regression testing of applications with external dependencies and the fate of programmers

I have been studying other things recently, so I have never prepared this blog. I will make it up today. Pai_^

I like to describe things quickly and easily, so I will not discuss it for a long time. In this case, we all know that one of the major advantages of TDD is the ability to automate regression testing. I don't want to talk about the advantages of automated regression testing here, so the purpose of this article is to explain how to writeAutomated regression testing codeTest applications with external dependencies.

When our code must rely on third-party things, our corresponding testing work will increase the difficulty and strength, for example, when we have database access or system file access. We usually call these third-party things an environment, and we need to add a lot of test cases for them, because the environment will change as it is deployed in different places. A headache is that, as a set of good test cases, each environment should be matched with the corresponding test cases, but the difficulty lies in how to create these test environments. For example, a program with database access, now I want to write test cases for it, according to the old rules, I need to develop positive test case, negative test case & boundary test case, among them, negative test case is to test how to prepare the environment if the database cannot be connected, the data cannot be read, and so on? It is impossible to disconnect the database during each test ?! In the face of similar problems, many people take the attitude of not testing, or they just want to manually test it when testing large-scale integration. The downside is that if your program does not handle exceptions well, you may only find it during large-scale integration testing, in addition, this will consume a lot of time to locate and solve it, because it has been a long time, maybe there are a lot of code dependent on this bug code, if your program does not have protection for automated regression testing (reconfigurable) if the design is highly dependent, it may take several hours to several days to solve a bug that can be solved within a few minutes.

So many excellent programmers finally chose to do the test (the vast majority also chose to do TDD ^_^). This is the fate that programmers cannot escape, not to increase their workload, on the contrary, it is designed to reduce your workload (and improve your efficiency) and reduce your headaches. When you are worried that you cannot find the correct location of a bug or a feasible solution to it. Another reason for TDD is that it forces you to write less dependent code to achieve the original design. I am not joking with readers. I think readers have heard of IOC or dependency injection? Yes, the two of them are the same thing and an OO design principle. This principle allows you to write code with weak coupling, because TDD is a test first, therefore, you will first write the test code. while writing the test code, you will naturally apply this principle, because only when the coupling is weak will the mock object have the opportunity to intervene, this naturally applies IOC to your design. This part is a bit esoteric. Besides, I am away from the question. I will discuss it later.

Since we have come to the conclusion that we must test it, we will naturally be concerned about how to test it. The breakthrough lies in how to perform tests independently of the environment, this is exactly what unit testing means. If we can do this without relying on the environment, that is to say, the test environment is all created by ourselves in the unit test code, so that we can get rid of the difficult and difficult problems of testing automation, but this is also the difficulty. How can we create a test environment in the test code? Someone came up with a good idea: "Let's simulate it. Of course, mock was already available in an unknown age, so future generations just borrowed this idea from other industries.

Now, in the database example, we can use mock objects to simulate data providers. What other data cannot be obtained !;) That's right. We use mock objects to get the desired results, so that we can successfully get rid of the external environment of the database, at the same time, we can simulate the database connection failure (an exception is thrown in the mock object ). Okay, there is no problem accessing the database. But what if the program depends on Web server? Stupid, won't it be the opposite? Of course it's the mock server. But pay attention to only the objects you really need mock. Do not mock the entire server, As long as mock outputs the server that is closely related to the part you want to test. I remember that a complete mocked server was created in the previous project. Through dynamic loading and configuration data, the mocked server can return the desired results, however, I personally do not recommend this approach, because the test has an additional layer of dependency, and now it is necessary to rely on the mocked server.

Okay. Pai_^

Http://files.cnblogs.com/cavingdeep/DbTestSample.zip

By the way, in the test coverage report of this example project, you can see that the coverage rate of my core section (the primary tested method with Data Access) is 90%, I did not cover 10% of it, but I did leave it out. I will give readers a chance to increase the core coverage rate to 100% !;)

Oh, by the way, let's add that the compilation script in the project is a gift for everyone, you will never find similar Nant scripts on the Internet that are specially prepared for various projects and are so practical and flexible .;)