Big talk rebuilding serialization 13: Automated Testing-it's not easy to love you

Just as many things have two sides, the same is true for the test method. To ensure that the test method is correct, the simplest and most intuitive idea is to write more test cases and test them from more perspectives, but this will inevitably increase our testing costs. Small steps require frequent tests. If the reconstruction cycle is 20 minutes, but the test takes 10 minutes, the cost will be too high. If the tests are manually tested by developers and the same tests are repeatedly executed dozens of times every day, the developers may be crazy.

You may think of automated testing immediately. Yes, in many refactoring books, Masters suggest that we first establish an automated testing mechanism before the refactoring starts. Unfortunately, after years of practice, my experience is that this is almost impossible. Every reconstruction we face is a legacy system. Most legacy systems share some common features: Messy code, no clear interfaces, high coupling between codes, and serious mutual dependency; the web layer, business layer, and data access layer often have no clear boundaries, and the code is mixed with each other. Under such circumstances, writing automated test code is almost impossible. Of course, the automated test code mentioned here refers to those automated test programs written based on JUnit.

For example, if you want to test an invoicing class and want to write its test code. Originally, this invoicing class was not complicated and its business was clear. However, when a function passes a parameter, one of the parameters is request, response, or session in the Web container. This is troublesome. To test a simple function, we must start the entire web application, which is unacceptable.

Then you may say, why do we have to pass a real request, response, or session? We have a fake mock! Good idea, but when you try mock, you will find that this is also an incomplete task. The request, response, or session has many states, and the attribute variables have objects and attribute variables. In addition, there are a large number of collection variables, which are all objects in the collection variables. Therefore, even if you make a lot of effort, the test may fail due to incorrect attributes.

Another taboo in writing automated testing programs is accessing the database. For example, if the insert operation is successful this time, it does not mean that the operation will be successful next time. The "primary key conflict" error will be reported in the next execution. This error is not caused by the program being tested, but by the test program. The result set generated by the last query is not necessarily the result of the next execution of the same query. The query results have changed. This does not mean that the program under test is wrong, but the test program is incorrect. To automate the execution of an automated test program, you must ensure that the test process can be executed repeatedly, and a definite result is returned at any time.

In short, automated testing is not a silver bullet, and not all code is suitable for automated testing. Code related to Web containers or other device drivers is not suitable for automated testing because we do not want to start web containers or other devices during testing. Therefore, before performing automated testing, we should first ensure that the program to be tested has been fully decoupled from the Code related to the Web Container or other device drivers. A better way is to separate the web layer from the bus layer. The web layer obtains data from the Web Container and package the data to the bus layer, the bus layer completes the business logic that really needs to be tested.

What is not suitable for automated testing is to access the database program, because the results of their execution are always related to the database status, and they cannot obtain stable and reproducible results. Therefore, the best solution to this problem is to drop the mock part of the database. How about mock? You cannot mock a jdbc or mock A hibernate, because it is too complicated. The only thing you can do is drop the mock of the DaO layer. This requires that the database access code be detached from the Business Code and written to the DaO layer during system reconstruction. Finally, the Dao-Layer Code of mock does not actually access the database. Each time a customer program passes in a parameter, it first serves as a test program to verify whether the parameter is as expected, and then returns a definite result.

Big talk rebuilding serialization 13: Automated Testing-it's not easy to love you