Test problem domain: Test double, and why the mock contention is wrong

Full testing is slow and difficult to locate errors, and the maintenance cost of the testing environment is also high. the solution is to convert to zero for separate testing. however, a new question is introduced: how to satisfy the requirements of a "part. the solution is a group of technologies called "test double. let's take a look at the mask issues.

• In order to compile and pass, I need to be satisfied with the dependency
• In order to run properly, I hope the implementation of the dependency should not be wrong.
• To cover actual use cases, I need to be dependent on simulating behavior in real scenarios, and I can specify different actions under different test cases.
• When I can't easily observe system status changes and make assertions, I hope I can go back and find that SUT (system under test) Interacts with external dependencies correctly.

The technical methods for solving these problems are dummy, Stub, fake, mock, etc. For details, referXunit test patterns. These technologies require SUT to program interfaces to avoid the complexity and difficulty of the test double implementation technology. generally, these test double types can be completed by manually writing a substitute class that implements an interface.

As a result, a new problem is introduced: manual Writing of substitutes is too cumbersome, manual work, repeated code, and a large number of test cases require a large number of substitutes. in particular, the substitute classes used to test interaction should be able to record and assert the input parameters and call sequence. to solve these problems, we need to design the substitutes. however, it is found that the language features provided by mainstream languages such as Java and C # can dynamically generate these substitutes, simplifying manual operations and the amount of code. therefore, these tools are manufactured and called mock tools.

In other words,The mock tool does not solve the dependency problem in the test, but the manual maintenance cost of implementing the dependent test substitute is too high.. (The support for "how to test interaction" is called a mock object)

------------- Actual separation line ---------------

The above is just an explanation of the wishful thinking of history. although according to Steve Freeman's description in the http://www.mockobjects.com/, Mock's idea does come from developers who don't want to just add a bunch of getters to the object to test and destroy the object-oriented, the mock technology was developed to support interactive testing. However, with the deep understanding of the mock technology and the increasingly powerful mock tool, there were two changes:

• Mock is no longer positioned as a test dependency isolation technology, but is used to support interface definitions between roles in the system: "It turns out to be less interesting as a technique for isolating tests from third-party libraries than is widely thought. mock objects is misnamed. it is really a technique for identifying types in a system based on the roles that objects play "(http://static.mockobjects.com/files/mockrolesnotobjects.pdf ).
• The increasingly powerful mock tool is used to support a different test world view: "system status is an unnecessary dependency, as long as the interaction is correct, therefore, I want all tests to be written in a correct way that the SUT (system under test) Interacts with external dependencies ".

The first change is not widespread, because it is not a technology that can be learned in a specific day, but a cognition related to experience. it may take time for less experienced people to develop software, and more experienced people have their own opinions.

The second change causes mock abuse. yes, powerful tools are easy to misuse: I can assert that the order of InterAction does not mean that all tests require the order of assertion. I can assert that parameters do not mean that I have asserted parameters for all tests. lack of recognition of application scenarios, lack of insight into the system, leading to a large number of vulnerable tests.What is really important is to identify the problem, and then select the appropriate tool. The mock tool also supports dummy, Stub, fake and other application scenarios. Do not waste these functions..

　

(For more information about mock, see the section "agile question: TDD", but your commonly used mock technology obviously pushes unit testing to a white box)