these are full of the "new" operators and are responsible for building the object graph of the application, but don't do anything else. • Business logic classes, which are devoid of the "new" operator and are responsible for doing work.
ask for all of the collaborators you need in your constructor. • But, if you find yourself needing to pass 10 collaborators to your constructor, maybe it's time to step back and think about the design
in a constructor, you will have to successfully navigate through on every instantiation • There's no way to mock or handle work inside constructor. (actually there’s but you don’t wanna do it) • Do as little work in constructor as possible (Ideally just assigning passed parameters to the instance variables).
of view is a real problem. • When tests modify global state, next run tests will be affected by this modification, this means that the order of the tests execution matters in this case. • Some tests can pass in isolation, but not when running them together. • Not sure about the current state of the global object. • Really hard to debug. • Tests cannot run in parallel.
All of the internal objects of the singleton are global as well. • The core of the issue is that the global instance variables have transitive property!
where you can divert the normal execution flow) • How much a static method will hurt from a testing point of view depends on where it is in the application call graph. A leaf method such as Math.abs() is not a problem. But it could stop being a leaf in any moment when functionality needs to be changed.