Test-Driven Development could more accurately be called "Client-
Driven Development." The practice encourages unit design to be
done starting from its API. Rather than conceive of an API
design in some kind of modeling tool, Client-Driven Design
practices force the designer (developer) to prove the value of
the API's design by experiencing it first. Client-Driven
practices such as TDD act as a kind of user-experience testing
for APIs, classes, and other modules. If you've ever worked with
an API that doesn't seem to make any sense to you as a
developer, then it's quite possible that the API was designed
using assumption-driven rather than test-driven development. All
the best assumptions in the world might not amount to much when
it comes down to using that API in real projects. Often, APIs
built using TDD are easier to work with, where APIs resulting
from assumption-driven development may cause unnecessary
friction, making it harder to achieve the level of feedback that
drives lean development, and reduces th