Test double

From Wikipedia, the free encyclopedia

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.

Uses[edit]

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.

Types[edit]

Test doubles are categorization many ways.

General[edit]

Although not universally accepted, Gerard Meszaros[1] categorizes test doubles as:

  • Stub — provides static input
  • Mock — verifies output via expectations defined before the test runs (differs from Mock object)
  • Spy — verifies output by asserting expectations after a test runs
  • Fake — a relatively full-function implementation that is better suited to testing than the production version; e.g. an in-memory database instead of a database server
  • Dummy value — a value that is required for the tested interface but for which the test case does not depend

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]

Service[edit]

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]

Verified fake[edit]

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]

See also[edit]

References[edit]

  1. ^ Meszaros, Gerard (2007). xUnit Test Patterns: Refactoring Test Code. Addison-Wesley. ISBN 978-0-13-149505-0.
  2. ^ Fowler, Martin (2007). "Mocks Aren't Stubs". Retrieved 2010-12-29.
  3. ^ Seemann, Mark (2007). "Exploring The Continuum Of Test Doubles". Retrieved 2010-12-29.
  4. ^ Clemson, Toby "Testing Strategies in a Microservice Architecture", martinfowler.com, 18 November 2014. Retrieved on 07 December 2017.
  5. ^ Byars, Brandon. "Testing Microservices with Mountebank", Manning Publications, MEAP began March 2017. ISBN 9781617294778. Retrieved on 07 December 2017.
  6. ^ Bryant, Daniel "API Mocking Tool WireMock v2 Released with Improved Request Matching and Stub Management", InfoQ, 16 August 2016. Retrieved on 07 December 2017.
  7. ^ ThoughtWorks "Technology Radar, Tools: Mountebank", ThoughtWorks, November 2015. Retrieved on 07 December 2017.
  8. ^ Bulaty, Wojciech "Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams", InfoQ, 19 February 2016. Retrieved on 07 December 2017.
  9. ^ Turner-Trauring, Itamar (2019). "Fast tests for slow services: why you should use verified fakes". Retrieved 2019-01-21.

External links[edit]

Gerard Meszaros:

Martin Fowler:

Open source: