11 ms·

I missed Part 1 so I went back to Part 1 of this series and I have to say, I don't agree with this approach at all. By only writing the simplest/most naive solu

by ebbv 10y ago

I missed Part 1 so I went back to Part 1 of this series and I have to say, I don't agree with this approach at all. By only writing the simplest/most naive solution to get your tests to pass maybe you are saving unnecessary work, but I feel like most of the time, and certainly in this example, you're just deferring work you know you're going to have to do. So instead of doing the work as you go through the tests you're pushing it all off to the end and then having to write the whole class in mostly one go. If instead you wrote what's necessary to pass each test properly as you went, you'd be building the class incrementally, and importantly you'd have a series of commits which each have worthwhile code in them instead of a bunch of useless slop.

eyelidlessness 10y ago
Honestly I think the real problem is the scope of the tests. The "red, green, refactor" approach is (despite conflicting ideologies) best suited to tests which express a behavior in the domain where you're trying to solve a problem. If you write a "unit" test where the "unit" provides some expected value or outcome absent meaning in the problem domain, of course the way to make the test "pass" is to hard-code some meaningless return value. If you write a test addressing a behavior relevant to the domain you're solving a problem for, and then create the conditions for that test to fail, you're almost certainly going to write code that is meaningful to solving that domain problem in order to make the test pass. The fact that the examples are using Rspec, a BDD framework, but writing traditional input->output test signatures, is a huge warning sign. Those kinds of tests are useful to catch boundary condition regressions (which is to say they're not totally useless; they should be written when there is hairy implementation-specific logic that needs to be preserved). But they're not going to help you write a program to solve a problem for human beings.
lgunsch 10y ago
Kent Beck talks about Triangulation in Test Driven Development by Example as just a tool to break out when you are stuck. He doesn't recommend it for every situation, but recommends it when you hit a road-block and need to back off and work around it.
- waterlink 10y ago
  While this is true, using this technique all the time makes me damn effective with it and I very rarely get stuck (only when I actually violate one of the rules). And I like the BabySteps feel that it produces, it is so nice to evolve your code bit by bit one test at a time and without harming Semantic Stability (you can read about it here: http://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html http://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTest... )

by ebbv 10y ago

eyelidlessness 10y ago

Honestly I think the real problem is the scope of the tests. The "red, green, refactor" approach is (despite conflicting ideologies) best suited to tests which express a behavior in the domain where you're trying to solve a problem. If you write a "unit" test where the "unit" provides some expected value or outcome absent meaning in the problem domain, of course the way to make the test "pass" is to hard-code some meaningless return value. If you write a test addressing a behavior relevant to the domain you're solving a problem for, and then create the conditions for that test to fail, you're almost certainly going to write code that is meaningful to solving that domain problem in order to make the test pass. The fact that the examples are using Rspec, a BDD framework, but writing traditional input->output test signatures, is a huge warning sign. Those kinds of tests are useful to catch boundary condition regressions (which is to say they're not totally useless; they should be written when there is hairy implementation-specific logic that needs to be preserved). But they're not going to help you write a program to solve a problem for human beings.

lgunsch 10y ago

Kent Beck talks about Triangulation in Test Driven Development by Example as just a tool to break out when you are stuck. He doesn't recommend it for every situation, but recommends it when you hit a road-block and need to back off and work around it.

waterlink 10y ago
While this is true, using this technique all the time makes me damn effective with it and I very rarely get stuck (only when I actually violate one of the rules). And I like the BabySteps feel that it produces, it is so nice to evolve your code bit by bit one test at a time and without harming Semantic Stability (you can read about it here: http://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html http://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTest... )