I think this comment, at the end of the readme, makes too strong a claim: "Write a failing test and see it fail so we know we have written a relevant test for our requirements..." While a test that passes at this point is clearly not a valid test, relevance cannot be assumed from its failure. Tests are not immune from simple coding errors like using the wrong comparison operator, and beyond that, it is possible that the programmer has misunderstood precisely what it means for the intended purpose of the code to be satisfied. I find that a few percent of my tests and assertions are actually incorrect as first written, for both of the above reasons.<p>If you are thinking that I am misunderstanding the purpose of unit tests in TDD, that it is only to check that you have written the code that you intended to write, then that would raise the question of how you address the issue of fitness for purpose - these are two distinct issues, even though the goal is for the former to match the latter.<p>Also, while a test may provide an easy to understand description of the failure, there is no guarantee that all possible failures are so described.<p>Teaching testing as a fundamental part of programming is important, and I like this approach, but I think this particular claim goes a bit too far.