agsandrew - Fotolia
Inside 5 types of test doubles
Spies, fakes and other nefarious-sounding test objects are actually beneficial to development teams. Learn about the five primary types of test doubles and when to use them.
Test double refers to any number of replacement objects that make testing easier. Test doubles stand in for software integrations or features that are not easily testable.
A good use case for test doubles is when a system or process -- while itself not error-prone -- adds a lot of time and effort to a test. Test doubles enable the developer or QA professional to focus on the new code and not the integrations.
There are five main types of test doubles:
- test stubs
- mocks
- dummies
- spies
- fakes
A web-based storefront provides many examples of how QA professionals can implement test doubles. Tests on an e-commerce site, for example, should allow QA to use fake credit card information to mimic real transactions. In this case, testers can create a simple fake credit card processing system, wherein any credit card number is valid. In another common scenario, an e-commerce site uses a third-party service to validate and process credit cards. To test such a system at all may require a replacement object, such as a test fake.
Test doubles are useful, but QA can only implement these objects if an app has the right test coverage. Only use test doubles in cases where the object or feature the test double is substituting for has been fully tested. Using test doubles will save QA professionals time and frustration by speeding up tests and skipping error-prone, unrelated steps.
Test stub
Test stubs fill in specific, hard-coded values to replace a value from outside of a test. Consider an e-commerce site. When testing a function to generate total order cost, a QA professional might have a list of items that are all test stubs rather than actual items. In production, a system would normally retrieve items' costs from a database or third-party service. But to facilitate testing that the function works correctly, test stubs provide arbitrary values.
Test mock
While test stubs store specific values, test mocks behave in a predetermined way. For example, testers can use a test mock in place of a function to authenticate a user. The mocked function always responds with a valid authorization token. It's common to have features that require authorization, but it can be time-consuming and tedious for each test to go through the steps to authenticate. By using test mocks for this function, QA can ensure the system always authenticates a user in a test scenario and focus instead on testing these features in isolation.
Test dummy
Test dummies exist for a system or tester to pass the dummy into a function; think of a crash test dummy. For example, a dummy could act as a test object for a customer review stage on an e-commerce site. The software would then pass the dummy to a function recordReview(CustReview review) that adds the review to a database. A test dummy allows a QA professional to only test the connection to the database, without having to verify the integrity of the data. Test dummies contain no data, but still satisfy the function requirements and call the function in order to validate the connection between the application and the database.
Test spy
A test spy is a double like a stub that also keeps track of information about its state and how a system uses it. That tracking aspect earned these doubles the name spy. Use a test spy, for instance, to keep track of the amount of times the object in question has been purchased. Test spies enable more complex test scenarios than other kinds of doubles.
Test fake
Test fakes simulate different test objects through a different implementation. To understand a test fake, think of the usage of in-memory databases for testing. Test fakes allow tests to validate functionality that QA would normally find too time-consuming or error-prone to test. These objects are often necessary to test applications that use multifactor authentication. Providing a valid MFA token from a test is vulnerable to errors, as these tokens are time-based. Faking the MFA validation ensures tests can skip this step and get to validating more important features of an application.
