3 ms·

No, but I should write one. Broadly speaking, I think test coverage in the real world, as practiced by effective programmers, is variable. One must use judgemen

No, but I should write one. Broadly speaking, I think test coverage in the real world, as practiced by effective programmers, is variable. One must use judgement to decide the appropriate level of test coverage. There are so many factors in making that judgement however that it's hard to distill. The primary heuristic I look for is "Do I have enough tests that I can be reasonably sure these tests will fail if I break the code". That is the fundamental question! This is different than the RSpec books' approach which is more dogmatic and highly structured (you need to test every function, every entry point, pretty much every single thing). The thing is, the RSpec book approach does work! It works better in fact! It also is a colossal waste of time. I'd write tests like that if I was writing a trading platform for the NYSE, but almost no one does that sort of work. Since I'm in the midst of writing a book (shameless plug http://exploringelasticsearch.com http://exploringelasticsearch.com ) I don't have time to writ e that post unfortunately.

ikawe 13y ago
Your post makes me feel like you're missing the point of BDD. The point of BDD isn't to "stop breaking the code". I think "coders" value "code" too much. The point of BDD is to build understanding of the problem you're solving by enumerating behavioral ambiguities/edge cases up front, before you've invested time and emotion into a particular code approach. You're using testable _behavior_ to drive the development of your code. More simply - test first, code second. Having a regression suite is a cool side effect. Of course, this is just how it's "supposed to work." In real life YMMV. Whether or not you think there's much value in that methodology is another story - but if you are going to dismiss something, you have to dismiss it based on a relevant metric.
- andrewvc 13y ago
  I agree! I like the idea of BDD. I disagree with the rspec book in degree, it goes overboard, too many tests for not enough return.
- btilly 13y ago
  Yes, you have just regurgitated the rhetoric. But there are a lot of problems which the enumeration you describe is simply the wrong way to build understanding. See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for an interesting example.

ikawe 13y ago

Your post makes me feel like you're missing the point of BDD. The point of BDD isn't to "stop breaking the code". I think "coders" value "code" too much. The point of BDD is to build understanding of the problem you're solving by enumerating behavioral ambiguities/edge cases up front, before you've invested time and emotion into a particular code approach. You're using testable _behavior_ to drive the development of your code. More simply - test first, code second. Having a regression suite is a cool side effect. Of course, this is just how it's "supposed to work." In real life YMMV. Whether or not you think there's much value in that methodology is another story - but if you are going to dismiss something, you have to dismiss it based on a relevant metric.

andrewvc 13y ago
I agree! I like the idea of BDD. I disagree with the rspec book in degree, it goes overboard, too many tests for not enough return.
btilly 13y ago
Yes, you have just regurgitated the rhetoric. But there are a lot of problems which the enumeration you describe is simply the wrong way to build understanding. See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for an interesting example.