I feel like a lot of these points are more about just having tests rather than writing tests first. Also, I think some of these points only make sense if you a

I feel like a lot of these points are more about just having tests rather than writing tests first. Also, I think some of these points only make sense if you already have a pretty good idea of what you are going to write. More specifically: 1. This may be the case but I don't think this requires that you write your tests up front just that you don't leave all of your testing until the very end 2. This is just about having tests 3. I don't really see why writing your tests up front would make them more complete unless you already know exactly what you want to build. I find that I often come up with most of my edge cases while I am writing the code. 4. In many cases, if you tests before you still don't know if your tests pass because of your code is good or because the test is bad. Many tests, up front, fail for very obvious reasons (such as the function you are testing simply doesn't exist yet). Just because they fail in the beginning doesn't mean they are good tests. What you actually want is mutation testing [1]. Testing up front is just a really crude version of this. I usually do mutation testing manually by removing the code I am trying to test, at the end, to ensure that my test fails if it is not there. 5. Again, just about having tests Ultimately I think you want interactive testing development. Write some code, write some tests, repeat. The actual ordering of the first 2 steps needs to be decided on a case by case basis. Writing all of your tests up front can be awkward. Writing all of your tests at the end is sometimes nearly impossible. [1] http://dev.theladders.com/2013/02/mutation-testing-with-pit-a-step-beyond-normal-code-coverage/ http://dev.theladders.com/2013/02/mutation-testing-with-pit-...