Test double

From Wikipedia, the free encyclopedia

In test automation, a test double is software used in a test that satisfies the interface of a dependency.

A programmer generally uses test doubles to isolate the behavior of the consuming code from the rest of the codebase.

Instead of providing the functionality of the production software, a test double is usually a simplified version and may include capabilities specific to testing.

Types[edit]

Gerard Meszaros[1] identified several types of test doubles:

  • Test stub — used for providing the tested code with "indirect input".
  • Mock object — used for verifying "indirect output" of the tested code, by first defining the expectations before the tested code is executed.
  • Test spy — used for verifying "indirect output" of the tested code, by asserting the expectations afterwards, without having defined the expectations before the tested code is executed. It helps in recording information about the indirect object created.
  • Fake object — used as a simpler implementation, e.g. using an in-memory database in the tests instead of doing real database access.
  • Dummy object — used when a parameter is needed for the tested method but without actually needing to use the parameter.

For both manual and automated black box testing of service oriented architecture systems or microservices, software developers and testers use test doubles that communicate with the system under test over a network protocol.[2][3] These test doubles are called different names depending on the tool vendor. A commonly used term is service virtualization. Other names used include API simulation, API mock,[4] HTTP stub, HTTP mock, over the wire test double[5] .[6]

Another form of test double is the verified fake, 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.[7]

While there is no open standard for the categories of test double, Martin Fowler used these terms in his article, Mocks Aren't Stubs[8] referring to Meszaros' book. Microsoft also used the same terms and definitions in an article titled, Exploring The Continuum Of Test Doubles.[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. ^ Clemson, Toby "Testing Strategies in a Microservice Architecture", martinfowler.com, 18 November 2014. Retrieved on 07 December 2017.
  3. ^ Byars, Brandon. "Testing Microservices with Mountebank", Manning Publications, MEAP began March 2017. ISBN 9781617294778. Retrieved on 07 December 2017.
  4. ^ Bryant, Daniel "API Mocking Tool WireMock v2 Released with Improved Request Matching and Stub Management", InfoQ, 16 August 2016. Retrieved on 07 December 2017.
  5. ^ ThoughtWorks "Technology Radar, Tools: Mountebank", ThoughtWorks, November 2015. Retrieved on 07 December 2017.
  6. ^ Bulaty, Wojciech "Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams", InfoQ, 19 February 2016. Retrieved on 07 December 2017.
  7. ^ Turner-Trauring, Itamar (2019). "Fast tests for slow services: why you should use verified fakes". Retrieved 2019-01-21.
  8. ^ Fowler, Martin (2007). "Mocks Aren't Stubs". Retrieved 2010-12-29.
  9. ^ Seemann, Mark (2007). "Exploring The Continuum Of Test Doubles". Retrieved 2010-12-29.

External links[edit]

Gerard Meszaros:

Martin Fowler:

Open source: