3 ms·

TDD is supposed to affect design in good AND bad ways. It is not true that TDD claims to have the best design, but the more testable. The first time I read abou

TDD is supposed to affect design in good AND bad ways. It is not true that TDD claims to have the best design, but the more testable. The first time I read about TDD it basically said testability > clarity. A succinct code that you dont know if its doing the right thing is worse than more verbose code that you can easily verify what it does. I do think that specifically with Rails, tests get so plentiful that they take long to run and it threatens the whole process. And the weight of testing models/controllers/integration is something that has bitten me before. Particularly, doing less integration and more model, because integration tests can be flimsy and slow an order of magnitude more. Since my first web programmer job, in 100% of my projects tests grew so big it took them minutes to run, making me nostalgic about the speed of Java tests I had for my first programming job.

marcosdumay 13y ago
> The first time I read about TDD it basically said testability > clarity. Now you scared me. I never tried TDD, and if that's a required tenet, I never will. This is completely upside-down. Tests can not verify that a program is correct.
- conanbatt 13y ago
  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.
  - marcosdumay 13y ago
    I'll argue that clarity makes it easier to understand the code. All cases of it. Not just the general case. Yet, I can see how one'd want to sacrifice a small bit of clarity to gain a big amount of testability. Thanks for the example.

marcosdumay 13y ago

> The first time I read about TDD it basically said testability > clarity. Now you scared me. I never tried TDD, and if that's a required tenet, I never will. This is completely upside-down. Tests can not verify that a program is correct.

conanbatt 13y ago
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.
- marcosdumay 13y ago
  I'll argue that clarity makes it easier to understand the code. All cases of it. Not just the general case. Yet, I can see how one'd want to sacrifice a small bit of clarity to gain a big amount of testability. Thanks for the example.