A mock is not a test of silver bullets.

Developers to write high-quality testing on the journey is full of thorns, databases, middleware, different file systems and other complex external systems exist, so that developers in the writing, running tests feel upset. Because external systems often run on different machines or in separate processes locally, it is difficult for developers to manipulate and control them in tests. The instability of external systems and network connections (the external system stops responding or the network connection times out) can cause the test run to fail randomly. In addition, the slow response speed of the External system (HTTP access, start service, create delete files, etc.) may also cause the test to run too long and cost too much. The problem is that developers are constantly looking for a cheaper way to test, and mocks are a recipe for developers to solve these problems. Mock objects run in a locally fully controllable environment, using mock objects to simulate dependent resources, allowing developers to easily create a stable test environment. Mock objects are created locally, and the features that run locally are more begotten to speed up testing.

The product that my team designed and developed is a continuous integration server, and the product features dictate that it needs to be integrated with various versioning tools (SVN, mercurial,git, etc.), build tools (ant, Nant, Rake, etc.) on various platforms (Windows, MAC, Linux, etc.) , the heavy reliance on external systems has put us in a lot of trouble writing tests, we naturally chose Jmock as a test framework, using it to isolate the impact of external systems on testing, and it's true that testing is easier to write, faster, and more stable after using the Jmock framework, What is surprising, however, is that the quality of the product is not as robust as we had expected with the constant addition of tests, although the unit test coverage of the product code is over 80%, it is often found that severe functional defects have to be performed in a round of repair defects and regression tests before a full test is issued. Why is it that a lot of tests are written and these problems happen frequently? Let's look at a real example before the discussion:

Our products need to be integrated with Perforce (a version management tool) to detect whether there is an update on the Perforce server for a certain period of time, and if so, to resolve the update to the modification object. This requirement is reflected in the code by first detecting the server update through the Perforce object and then parsing the standard output (stdout):

public class Perforcematerial {
private Perforce Perforce;
.....
.....
Public List findmodifications (date start, date end) {
String changes = Perforce.changes (start, end);　　　　　　　　Detects updates, returns the command line standard output (stdout)
List modifications = parsechanges (changes);//resolves standard output to modification
return modifications;

private List parsechanges (String output) {
//stdout resolved to modification object through a regular expression
}
  public class Perforce {public
String changes (date start, date end) {
//updates are detected by the command line, and standard output from the command line (Stdou T) return
}
}

The corresponding mock test is also very easy to understand:

.....
.... @Test public
void Shouldcreatemodifiationwhenchangesarefound () {
final String stdout = ' Chang 4 on 200　8/09/01 by P4user@dev01 ' Added build.xml ' ";　　　　　　　　Set the standard output sample
final Date start = new Date ();
Final Date end = new Date ();

Context.checking (new Expectations () {One
(perforce). Changes (start, end);
Would (ReturnValue (stdout));
)//sets the behavior of the Perforce object to return the set stdout

list = perforcematerial.findmodifications (start, end);//Call the method being measured 
  
    Assertthat (List.get (0). Revision (), Is ("4"));
Assertthat (List.get (0). User (), is ("p4user@dev01"));
Assertthat (List.get (0). Modifiedtime (), is ("2008/09/01"));
}