Only proof can verify a program is correct, and that is so cumbersome and expensive is done on rare critical operations. Tests give you the ability to know how

Only proof can verify a program is correct, and that is so cumbersome and expensive is done on rare critical operations. Tests give you the ability to know how a certain code behaves in specific circumstances. Clarity makes it easy to understand the general case. So if the clarity of the general case is a little worse to be able to test the outlier cases as well, the TDD philosophy would welcome that trade. Or at least, thats how I understood it. A brute and unpolished example of clarity vs testability: A) def complicated_algorithm(input) mod_input = Math.root(input) mod_input = input / mod_input ... end def division_in_complicated_algorithm_test input = 1 input.should_receive(:/).and_raise(ZeroDivisonError) Math.root.should_receive(input).and_return(0) complicated_algorithm(1) end ----------------- B) def complicated_algorithm_testable_version(input) mod_input = Math.root(input) mod_input = divide(input, mod_input) ... end def divide(a,b) a/b end def divide_test assert_exception ZeroDivisionError, divide(1,0) end Overall, the point of doing tests first is that you dont hack them together doing complex dependency injections, because naturally to save work you do the easy test..at some expense of the final code. In the above example, the top example is less verbose, having one full less method, but the test is more complex and fickle, because it was done to verify the above code. Its not a fantastic example, we could argue that the tests try different things, and that division is too silly to put into a different method. The point is that the above happens when you write code first , test later, and the bottom one happens the other way around. TDD advocates for testability over clarity.