Unit Testing is great. In an environment where data is assumed, a system that successfully passes the test can be regarded as a good system.
However, it is now possible to directly connect to external resources for integration testing to make the program more valuable. Who knows what the content vendors (suppliers, vendor) will do!
Many people have been trying to make the test reach 100% code coverage, which is a great idea, but I think it has some basic conceptual problems. Lostechies, Ryan
Svihla proposed "anti-pattern", with an interesting view: "Most applications need to interact with external resources ". They have many good arguments, such:
Most unit tests require a running database, webpage, or application server.
Indeed.
All related to data and external systems
I will prove below that most bugs do not come from the program itself, but are caused by data input from the outside.
Why? Because Bugs usually occur in the actual working environment, our program will not be able to process the raw data input by the external system, or the data output by the program to the external system. Unit testing or TDD emphasizes the provision of a set of hypothetical data to test whether the program can run as expected. That is to say, the entire test is carried out in a hypothetical environment. This is why the interface is always so easy to run successfully. In addition, automation, pre-testing, and repeatable testing can be achieved. However, there are still many systems that cannot solve practical problems.
This test method can only solve part of the problems faced by software development. How can we discover real problems? In the end, you need to connect your software to its external resources for discovery.
A slightly abstract example:
1) some data from external systems.
2) The application starts to process the data.
3) The application sends the processed data to the external resource (generally different from the data in step 1)
4) external data is processed in step 1 and then sent to the application.
5) receive and process the data again.
This is repeated.
We usually use mocks/stubs or similar programs to generate Step 1 data for Step 2 testing, and the data used in step 1 testing is also produced in a similar way. Steps 1st and 4th are unreliable and unpredictable, because you do not know what data the external system will give you.
Steps 1st and 4th are the most important aspects of applications in the launch environment.
External systems are very picky (
External systems are finicky mean things)
For some e-commerce systems, financial systems, and various interfaces, various types of data are transferred between systems.
Let's talk about some high-level issues:
1) Ideally, when the external system changes the data to be sent, whether in format or schema, you want to know in advance. This is wishful thinking. Recently I added a column to the tax information of an external data system with an e-commerce system that requires applications to adjust internal logic. This is what we know when the external data system has started to send data.
2) Ideally, when an external system claims to support new APIs, you should change the internal logic of the application and send new data. Finally, you will find that they support new APIs, either in their UAT (User Acceptance Test) environment rather than in the production environment, or, it is only in the launch environment, not in The UAT environment.
3) Your program has used the procurement information about domestic assets smoothly, and the external systems and procedures are also well coordinated. When you start to add some international asset information, you may not be able to find that the data has completely changed.
These are the scenarios I have encountered. I would like to say that in unit testing, you cannot understand the environment you will face in the future, and there is only a way to do it during actual operation. What's even more sad is that the problems that call you at three o'clock in the morning usually come about like this.
How to complete the test specifications (how to setup your specs)The design also begins with the specification document. Specification is actually another test (well-crafted tests ). I will differentiate the unit and integration in the specification and write different code.
The test specification of the so-called "unit" is to test the internal business logic to see if everything is serialized. It is to provide some scenarios during the test to ensure that the program executes the correct logic and outputs the expected results.
The integration test specification is related to external resources. Provides a set of external resource data and the data to be returned. These are the things actually concerned about in integration testing.
Interaction with external resources can truly determine whether the program can work normally.[Only major concepts are translated. For details, please read the original article! The original intention of translation is that it is found that the definition and maintenance of interfaces are often inadequate, and the independent verbal communication by engineers often brings high risks. This article brings us a bit of thought and reexamines whether the interface at work has been fully valued.]
Original article address: more reasons why integration tests can be more important
Than unit tests reprinted please indicate the source: http://blog.csdn.net/horkychen
