In computer programming and computer science, programmers employ a technique called automated unit testing to reduce the likelihood of bugs occurring in the software. Frequently, the final release software consists of a complex set of objects or procedures interacting together to create the final result. In automated unit testing, it may be necessary to use objects or procedures that look and behave like their release-intended counterparts, but are actually simplified versions that reduce the complexity and facilitate testing. A test double is a generic (meta) term used for these objects or procedures.

Types of test doubles

Gerard Meszaros[1] identified several terms for what he calls, "Test Doubles." Using his vocabulary, there are at least five 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 test double and the various types, there is momentum for continued use of these terms in this manner. 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

References

  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.

Gerard Meszaros:

Martin Fowler:

Open source:

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.