It is not always trivial to write a unit test for every aspect of a system’s behavior. What about GUIs? What about EJBs and other creatures whose lives are managed by container-based frameworks? What about databases and persistence in general? How do you test that an exception gets properly thrown? How do you test for performance levels? How do you measure test coverage, test granularity, and test quality? These questions are being answered by the Test-First commmunity with an ever evolving set of tools and techniques. Tremendous ingenuity continues to pour into making it possible to cover every aspect of a system’s behavior with unit tests. For example, it often makes sense to test-drive a component of a system in isolation from its collaborators and external resources, using fakes and Mock Objects. Without those mocks or fakes, your unit tests might not be able to instantiate the object under test. Or in the case of external resources like network connections, databases, or GUIs, the use of the real thing in a test might slow it down enormously, while the use of a fake or mock version keeps everything running quickly in memory. And while some aspects of functionality may always require manual testing, the percentage for which that is indisputably true continues to shrink.

Source: https://www.versionone.com/agile-101/agile-software-programming-best-practices/test-first-programming/