A test double is software used in software test automation that satisfies a dependency so that the test need not depend on production code. A test double provides functionality via an interface that the software under test cannot distinguish from production code.
A programmer generally uses a test double to isolate the behavior of the consuming code from the rest of the codebase.
A test double is usually a simplified version of the production code and may include capabilities specific to testing.
Test doubles are used to build test harnesses.
A test double may be used to simplify and speed test execution.
For example, a program that uses a database server is relatively slow and consumes significant system resources which impedes testing productivity. Also, a test case might require values outside those stored in the database. A test double might provide a static value instead of accessing a database.
A test double may be used to test part of the system that is ready for testing even if its dependencies are not.
For example, in a system with modules Login, Home and User, suppose Login is ready for test, but the other two are not. The consumed functions of Home and User can be implemented as test doubles so that Login can be tested.
Test doubles are categorization many ways.
Although not universally accepted, Gerard Meszaros[1] categorizes test doubles as:
While there is no open standard for categories, Martin Fowler used these terms in his article, Mocks Aren't Stubs[2] referring to Meszaros' book. Microsoft also used the same terms and definitions in an article titled, Exploring The Continuum Of Test Doubles.[3]
For service oriented architecture (SOA) systems and microservices, testers use test doubles that communicate with the system under test over a network protocol.[4] [5] These test doubles are called by different names by the tool vendors. A commonly used term is service virtualization. Other names used include API simulation, API mock,[6] HTTP stub, HTTP mock, over the wire test double[7] .[8]
A verified fake is a fake object whose behavior has been verified to match that of the real object using a set of tests that run against both the verified fake and the real implementation.[9]
Gerard Meszaros:
Martin Fowler:
Open source: