Mocking
Everyone who has done any of the applications more complicated than Hello World knows that Java code is full of dependencies. There can be classes and methods written by other members of the team, third-party libraries, or external systems that we communicate with. Even libraries found inside JDK are dependencies. We might have a business layer that communicates with the data access layer which, in turn, uses database drivers to fetch data. When working with unit tests, we take dependencies even further and often consider all public and protected methods (even those inside the class we are working on) as dependencies that should be isolated.
When doing TDD on the unit tests level, creating specifications that contemplate all those dependencies can be so complex that the tests themselves would become bottlenecks. Their development time can increase so much that the benefits gained with TDD quickly become overshadowed by the ever-increasing cost. More importantly, those same dependencies...
