The idea behind test-driven development is that your tests are written in the form of scripts, running through the flow that a user or client package would take if they made use of the software you are about to write.
Obviously at first your test classes will be full of errors which complain that the classes and methods don't exist (or they do exist but simply throw an exception which says that the method has not yet been implemented). But, once your test script outlines the scope and expected behaviour of these embryonic methods, the next step is to write code for all of those classes and methods, and keep running your test scripts until every test passes.
Alongside these flow scripts, you need to have unit tests which attack every method with every type of valid and illegal parameter. Tests should exist to make sure that null parameters, empty/zero parameters, and parameters of the wrong form are handled appropriately, either by throwing an exception in the case of invalid data or returning the result expected in the case of valid data.
Even if you set out to write all tests before writing any actual application code, you'll probably find that you end up writing new application code before writing tests for it, at least some of the time.