Plida Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Sources: 
  - Software Testing course at ITMO university by Kochubeev Nikolay Sergeevich 
  - [[https://ahmadgsufi.medium.com/test-doubles-understanding-the-different-types-and-their-role-in-testing-67cbf71ea252]]
  - [[https://medium.com/@Omid_dev/understanding-mock-dummy-spy-stub-and-fake-in-php-unit-testing-b8c03b323d0e]]

====== Test doubles ======

Test doubles are used in [[unit_test|unit tests]] to mimic the real objects the [[software_testing|tests]] depend on.


==== Test double types ====

There are several test doubles types:

  * dummy;
  * stub;
  * fake;
  * spy;
  * mock.

=== Dummy ===

Dummy is an object that's not actually used in the test. It is used as a placeholder, for example, when there needs a certain type of object to be passed as a parameter to initialize a method.

=== Stub ===

Stubs provide predetermined responses. They're used to isolate the behavior of the component from its dependencies. They're typically used to simulate the behavior of complex or external components (data bases, web services, external API).

=== Fake ===

A fake is a simplified real object. They're used for tests that require a real implementation but a lighter and faster one.

=== Spy ===

Spies record information about how they were interacted with during the test (how many times was the method called, what arguments were passed, the order of method calls).

=== Mock ===

Mocks are used to verify that certain interactions took place by being pre-programmed to expect certain specification of the calls.

==== Anti-patterns ====

FIXME

=== Over-mocking ===

If the mock expects way too specific calls, the test no longer checks for the behavior, but for the inner details of implementation.

=== Testing implementation instead of the behavior ===

When a test knows too much about the inner workings of the class (what methods are called and in what order). The slightest refactoring can break such a test.

==== Best practices ====

  - Choose a correct test double.
  - Give preference to fake where it's appropriate, as it's easier to maintain than mocks.
  - Limit the amount of mocks. If a test requires more than 2-3 mocks, something went wrong.
  - A test must fixate the business-result, not the inner details.
  - Take out the creation of doubles into factories or test data builders. This improves readability.
  - Use mocks/fakes for unit-tests, for integration -- real services.
  - Use clear names (SpyEmail, FakeRepo).