proton-mail-android/docs/0004-define-mocks-with-explicit-behaviour.md

Define mocks with explicit behaviour

• Status: Accepted
• Deciders: Marino, Zorica, Stefanija, Davide, Tomasz, Maciej
• Date: 02/09/2021

Context and Problem Statement

Using mocks, specially relaxed mocks ( mockk(relaxed = true) ) could lead to unexpected test behaviour and consecutive difficulty to understand why a given test is failing.

In the episode that gave birth to the discussion, we had a relaxed mock for a Component used by our SUT; previously the SUT was internally calling Component.getSomething: Something, while now is calling Component.observeSomething: Flow<Something>, but being this Flow<Something> a mock generated by the parent, it was never emitting. Here, without a relaxed mock, we would have seen the error "Component.observeSomething is not mocked", highlighting the reason of the test failure.

• We want a solution that allow us to read a test behaviour in the easiest way possible, without hidden behaviour
• We want our tests to be reliable

Decision Outcome

• We should never use relaxed mocks
  • acceptable if its declaration is internal to a single test case, ensuring a good degree of control an isolation
• It can be ok to use mockk(relaxedUnitFun = true), as the result will be what we expect: an Unit

Consequences

1. We should stick to what agreed here going forward, aiming to replace the current mocks in the project