This document discusses the Test Double pattern, which involves replacing components that a system under test (SUT) depends on with simulated equivalents for testing purposes. There are three main types of test doubles: static fakes, which use hardcoded behavior; dynamic fakes, which have configurable return values; and mocks, which allow specifying expected inputs and outputs. Test doubles make tests faster and more isolated by removing dependencies, but can make test scenarios less clear and require maintenance. The document advocates using doubles along with other test types like contract tests and tests of the dependent components themselves.

1. Test Double Pattern
Fake it 'til you make it

2. Ivan Pashko
● Project Manager Scrum
Master
● QA Automation Engineer
● 10+ years in IT
● 1+ years happy father

3. "Fake it 'til you make it" is a common
English idiom, which suggests that by
imitating confidence, competence, and
an optimistic mindset, a person can
realize those qualities in real life (c)
Wiki.

4. Idea, not a solution

5. Live Software Problems
• Complex
• Slow
• Unavailable
• Brocken
• Unstable

6. E2E Tests Problem
• Complex
• Slow
• Fragile

7. What problems we solve
● Imitate simple 3rd Party services
○ FBGoogle authentication
○ 404 / 500 / 401 service responses
● Simple API Methods
○ Hardly-configured data responses
○ Test flowscenario edge-cases
○ Stub ajax-calls on frontend
● Replace Data Services, DBs

8. Test Double Pattern
Idea of pattern, is to replace a component on which
the SUT depends with a “test-specific equivalent”

9. Test Stub

10. Mock Object

11. Static Fake
Scenario: Visa deposit positive flow
Given Visa deposit payment method with customer defaultCustomerForDeposit
When Fill payment information
And Process fake deposit with 155.5, status Captured and Code 30000
Then Receipt page should be displayed with correct information
Scenario: Visa withdraw positive flow
Given Visa withdraw payment method with customer
defaultCustomerForWithdrawal
...
When Process fake withdraw with 10.1 and status Created
Then Receipt page should be displayed with correct information

12. Fake?

13. Fake? Why?
● Flexible
● Understandable
● Applicable
● Usable

14. N+1 or Math induction
● A is depend on B
and C
● So, to test A we
do ABC testing

15. N+1 or Math induction
Step N+1 - testing B, C as it
an A
Request:
● Test A→B
● Test A→C
Response:
● Test B→A
● Test C→A

16. N+1 or Math induction
Step N - test A without B &
C, replacing with the
Doubles
● Now we have only A
(and controlled double
B’ and C’)

17. Static Fake
HardСoded behavior of dependent component.

18. Static Fake
Scenario: Visa deposit positive flow
Given Visa deposit payment method with customer defaultCustomerForDeposit
When Fill payment information
And Process fake deposit with 155.5, status Captured and Code 30000
Then Receipt page should be displayed with correct information
Scenario: Visa withdraw positive flow
Given Visa withdraw payment method with customer
defaultCustomerForWithdrawal
...
When Process fake withdraw with 10.1 and status Created
Then Receipt page should be displayed with correct information

19. Static Fake
{
case "default_Customer_With_Accounts":
return FB_.CreateDefaultCustomerWithAccounts(cGuid,
siteName)
.Build();
case "default_Customer_for_Withdrawal":
return FB_.CreateDefaultCustomerForWithdrawal(cGuid, siteName)
.Build();
case "default_Customer_with_all_Payment_methods":
return FB_.CreateDefaultCustomerWithAccounts(cGuid, siteName)
.Build();
case "default_Customer_with_Pending_Withdrawals_Deny_cancellation":
return FB_.CreateDefaultcustomerWithPWDDenyCancellation(cGuid)
.Build();
…….

20. Pros & Cons
+
● Contains all specific
behaviors
● Any language for
implementation
● Use for prototyping & local
testing
● Speedup tests
-
● Test scenarios are not
clear (logic hidden in
implementation)
● Need to be supported all
the time (for all new logic)

21. Dynamic Fake
Reusable Test Double with the configurable values to
be returned or verified during the fixture setup phase
of a test.

22. Dynamic Fake
Scenario: Single currency limits on withdrawal method page
Given Customer has payment methods
| PaymentMethodName | MethodAction | IsAvailable |
| Visa | Withdrawal | true |
And Customer has Visa Withdrawal saved accounts
| MaskedCardNumber | CardHolderName | ExpiryMonth | ExpiryYear |
| 498765******9236 | Test Name | 07 | 2019
|
And Customer balance 2000 EUR
And Customer has Visa withdrawal payment method limits
| Currency | Min | Max |
| EUR | 21 | 1200 |
And Push customer to fake
When Customer opens Withdraw Visa page
Then MinLimit is 21 and MaxLimit is 1200

23. Dynamic Fake
Scenario: Single currency limits on withdrawal method page
Given Customer has payment methods
| PaymentMethodName | MethodAction | IsAvailable |
| Visa | Withdrawal | true |
And Customer has Visa Withdrawal saved accounts
| MaskedCardNumber | CardHolderName | ExpiryMonth | ExpiryYear |
| 498765******9236 | Test Name | 07 | 2019 |
And Customer balance 2000 EUR
And Customer has Visa withdrawal payment method limits
| Currency | Min | Max |
| EUR | 21 | 1200 |
And Push customer to fake
When Customer opens Withdraw Visa page
Then MinLimit is 21 and MaxLimit is 1200

24. Pros & Cons
+
● Have all specific
behaviors
● Configured from test
● Scenarios are clear &
readable
-
● Hard for development
● Can’t/hard to used for
prototyping or local
testing

25. Double problem - No thruthworsy

26. Test with Double Vs Consumer Tests
Test with Double (N)
Given Customer exists on Facebook
And Allowed to authenticate to MySite
When Open MySite
#Send requests to FB Auth service
And Authenticate via Facebook
#FB returns “Success” response
Then “Success login” message appears
Consumer test (N-1)
Given Customer exists on Facebook
And Allowed to authenticate to MySite
When Send requests to FB Authservice
Then FB returns “Success” response

27. And so
● Using of Test Doubles -
○ could make your life easier
○ your tests: faster, stable, possible
● Doubles Pattern – not a silver bullet
● Additional test layer:
○ Contract tests
○ Depended component tests

28. Thank you! Questions?