Performing non-mock, state-based unit testing of non-trivial functions and their dependencies that follow CQS

Question

I realize that this question may seem to be a duplicate of questions such as this, this, this, this, and this. I\'m specifically asking, however, how you would write unit tests

Answer 1

Should you use the real implementation of a given dependency or a fake class?

As your own experience shows, overutilization of mocks makes tests brittle. Therefore, you should only use mocks (or other kinds of test doubles) if there is a reason to do so. Good reasons for using test doubles are:

• You can not easily make the depended-on-component (DOC) behave as intended for your tests. For example, your code is robust and checks if another component's return state indicates some failure. To test your robustness code, you need the other component to return the failure status - but this may be horribly difficult to achieve or even impossible with the real component.
• Does calling the DOC cause any non-derministic behaviour (date/time, randomness, network connections)? For example, if the computations of your code use the current time, then with the real DOC (that is, the time module) you would get different results for each test run.
• Would the result that you want to test be some data that the code under test passes to the DOC, but the DOC has no API to obtain that data? For example, if your code under test writes its result to the console (the console being the DOC in this case), but there is no possibility for your tests to query the console what was written to it.
• The test setup for the real DOC is overly complex and/or maintenance intensive (like, need for external files). For example, the DOC parses some configuration file at a fixed path. And, for different test cases you would need to configure the DOC differently and thus you would have to provide a different configuration file at that location.
• The original DOC brings portability problems for your test code. For example if your function hashPassword uses some cryptographic hardware to compute the hash, but this hardware (or the proper hardware version) is not available on all hosts where the unit-tests are executed.
• Does using the original DOC cause unnacceptably long build / execution times?
• Has the DOC stability (maturity) issues that make the tests unreliable, or, worse, is the DOC not even available yet?
• Maybe the DOC itself does not have any of the abovementioned problems, but comes with dependencies of its own, and the resulting set of dependencies leads to some of the problems mentioned above?

For example, you (typically) don't mock standard library math functions like sin or cos, because they don't have any of the abovementioned problems.