I write high level automated tests immediately at the beginning of a project, which have several upsides: They can be read almost like project requirements, so

I write high level automated tests immediately at the beginning of a project, which have several upsides: They can be read almost like project requirements, so they double as validation for solving the problems in the reqs. They only use the outermost APIs of your code, which will change much less than internal module APIs, and so won't inhibit changes and experimentation as much. They enable you to automatically test your code in the "real" scenarios that your project reqs describe, instead of just module-level tests that may not catch bugs in API usage of those "real" scenarios. Later on in the project, as larger internal modules crystallize, you isolate those modules with their own outer APIs and write automated tests for their APIs. Yes, this has downsides. High level white box testing exclusively during early stages obviously won't catch all your internal error cases early. However, I have found them to have superb ROI, especially in projects where time constraints have required pragmatic approaches. YMMV.