Use analog object to solve the problem
Traditionally, the term tested terms have already included the concept of drive and stub. In your career as a software developer, you may create considerable number of these drivers and stubs for each module you need to test.
The drive is a program written in a single purpose of the properties and methods in the library, and uses it to test the functions in this library. The stub is also a program, its purpose is to provide an execution environment that may be interacting with other modules to be interacting with other modules.
As shown in Figure 2, this concept is well transformed into application terminology. In these available tools, you have a framework that can perform drivers and stubs simultaneously, and you can use it in a flexible dynamic manner. On the driver execution, I use NUNIT (current version 2.2); on the execution of the stub, I use NMOCK (current version 1.1) to create a dynamic analog object at runtime. If returned to Figure 1, an analog object has replaced the data access layer to execute the iMyDataAccess interface. NMOCK can create such an analog object at runtime.
Note that NMOCK uses the reflex mechanism to create an analog execution environment at runtime, so use nMock, use NMOCK, use the encoding of the interface to replace the execution environment. Since this is already a great way to be praised, NMOCK helps strengthen this important design technology.
