Wherever possible, I try to avoid using mocks as they just end up obscuring what the code is doing. More specifically, I follow the maxim of only using in the

Wherever possible, I try to avoid using mocks as they just end up obscuring what the code is doing. More specifically, I follow the maxim of only using in the tests what is publicly available to a user of the class. If it is a private instance of a class, or a class created in a function that does not have a mechanism to be switched for something else, you shouldn't be poking the internals to modify it, you should either: 1. provide a mechanism to change that class -- e.g. if the class under test is talking to a database; 2. not change the code -- e.g. if the class under test is using a particular data structure class. You should not have/use mocks if you have a class A that holds and uses class B to perform its work. If you do, you are not properly testing class A's behaviour. That is, if you have a rotation helper class that uses a quaternion class, you shouldn't be mocking the quaternion class behaviour -- that way only leads to madness, expecially if the internal implementation of the rotation class changes its internal representation/logic to use matrices. Acceptable places to use mocks or similar techniques are: 1. for the class that wraps the database object, or some other external system -- for which, I don't class the filesystem to be external; 2. for setting up parts of an application (e..g IntelliJ) when testing a plugin -- and there, I try to get as close to the application behaviour as possible/necessary to perform the tests (i.e. wherever possible, use the application's real implementation class). 3. for setting up things like Spring, or other dependency injection components.