Tests can be written before, during, or after coding the project. Test-Driven Development (TDD) uses the idea of short development cycles, with each cycle based on a set number of features to implement. Prior to coding, tests are written (and expected to fail) that dictate the end states of the different features. The actual code is written with an eye to making the tests pass; once a test passes, no further work is necessary for that particular feature.

The problem with TDD is that it focuses on small portions of the overall project, but doesn't necessarily address full functional testing of the product. It also means that management has to support the TDD paradigm. Many managers feel testing is a waste of time or, at best, left until the end of the project; they often feel that writing tests doesn't add to meeting deadlines because it isn't functional code.

TDD also means that the tests need to be thought out and designed to address the needs of the project. Since the main code is written to make tests pass, it's entirely possible that portions of the project aren't written because someone forgot to write the tests for it.

More common, at least in this my experience, is testing after development. While a variety of agile programming techniques dictate how the project code is written, the tests are written after most of the project is completed.

The advantage is that all aspects of the project can be tested, because the developers already known what is present. A disadvantage is that some of the project code could be wasteful if it was written without a purpose; in other words, while TDD allows the programmer to stop writing code when a test passes, writing tests after the fact means that more tests may have to be written, and some project code may have been written that wasn't necessary to meet project requirements.

Ultimately, while it is better to test early and test often, having tests at all is more important than not having any tests.