yitzhakbg wrote:
This might be a loaded question on this forum, but here goes: Just had a discussion with a prospective employer, a Ruby On Rails shop. His reaction to BDD development on every project was skeptical, saying something like: "It depends on the project". "Some jobs are so short that the extra time invested in developing tests doesn't justify the cost". He was insistent that writing tests costs more. After all, you write twice: first the tests, then the code (or the other way 'round). My question is: From hard, practical, cold real world experience, is that so? Is BDD development more expensive? Let me qualify that. One could answer, "no, since the tests save you pain and heartache down the line". The question is whether BDD coding with RSpec is more expensive in the implementation phase and how much truth there is in the statement that BDD isn't for every project, like quick knock ups for example?
Does TDD/BDD take longer that hacking something out? I would say that it depends a lot on the project and the developer's experience in that domain, BDD, and doing BDD in that domain. That said, it probably isn't an unfair generalization to say that quick short jobs can be hacked together faster without tests. Prototyping, spikes, and exploring new technology are times when BDD would probably hinder you. As you point out though you will be building up a technical debt by not having tests that will come back and bite you at sometime. That is why I generally throw away any prototype code and start over with a blank slate that I can start doing BDD with along with my newly gained knowledge from the prototype. I have experiences where doing BDD has greatly sped up my development and has helped me in compartmentalizing a complex problem into smaller more manageable sub-problems. For a "quick knock up" then I think it it good to ask how long this software is suppose to live, and whether or not the developers have enough discipline to start adding tests once it does become more complex. If the answer to the latter question is no then forgoing tests in the beginning sounds like a recipe for disaster. I suppose another question is how important this piece of software is. If it is just for fun and you just want to see some results and could care less about maintenance down the line then manual testing is just fine.
One more thing... you said "The question is whether BDD coding with RSpec is more expensive in the implementation phase...". BDD is not just the implementation phase but is also the design phase as well. I could certainly throw together some systems faster without doing BDD and then manually test the system afterwards. Would I have confidence in the system? Yes. In fact, I would have just as much confidence in the system as I would if I had a spec/test suite verifying the behavior. However, if I had created that system with TDD/BDD from the start I would end up with a greater sense of confidence of the *design*. Easily tested code tends to go hand in hand with good design, where hard to test code tends to carry some code smells resultant of a poor design. Which is another danger in delaying creating an automated suite because you may end up with hard to test objects which will be in dire need of some refactoring.
I don't know if I really answered your question or if I just added to your confusion. In the end BDD, just like any other practice, has its trade offs and should only be applied in the right situations. I think the "right situations" will vary from developer to developer/team to team and there may not be one single rule for where the exact cutoff is.
-Ben _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
