Test Doubles in Automated Testing

Introduction: Why do Test Doubles Matter? Real collaborators like databases and third-party APIs can make tests slow and hard to control. Test Doubles replace them with simpler alternatives when needed, but knowing when to use them and when to use real objects is just as important. Nomenclatures and concept definitions follow Gerard Meszaros and Martin Fowler. References are at the end of the article. First: General Test Nomenclatures SUT: System Under Test. It is the main (class, object, function, etc.) being tested. Collaborators: "Secondary objects", they are not the main object like the SUT, but are necessary to test the SUT. Observation Point: Provides the ability to analyze the interaction between the SUT and other parts of the system after exercising the SUT. Indirect Input: When the behavior of the SUT depends on values returned by another component whose services it uses. Indirect Output: Calls the SUT makes to its collaborators (e.g. saving to a repository) that are not visib