We already know that tests are meant to verify that our software adheres to the desired behavior. To do so means that our tests must express what that desired behavior is. They must explicitly state, "If I do this, I expect that to happen."
For the innermost components, what happens is probably an implementation detail: "If I commit my unit of work, data is written to the database." But the more we move to the outer parts of our architecture, those that connect our software to the outside world, the more these tests become expressions of business needs. The more we move from solitary units, to sociable units, to integration and acceptance tests, the more the "desired behavior" becomes the one that has a business value.
If we work with a test-driven approach, our first step before writing implementation code is obviously to write a test that helps us understand what we want to build (if we are just starting with our whole project...
