Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have my own little project I am creating using RoR, I plan it to have small-medium load.
With no doubt I started with BDD and TDD (Cucumber and RSpec to be exact, but I am also experienced with TestUnit), I like it but since it's my own project and it's a somewhat startup - I am changing many things in it, many requirements, many ideas how things should work and look. So it becomes too much time-consuming to always code it using BDD and TDD, even if I cover only common cases.
What should I do? Should I sacrifice BDD and TDD for productivity till I get to some point when I have a solid basis and it's time for production, and than I write tests?
Should I write them right now but as minimal as possible? Should I only write RSpec and forget about Cucumber for now? Or maybe just TestUnit to test model for now since it's the most important and everything else can change?
Thanks in advance!

Update:
I know all the pros of TDD and BDD, by no means it makes it easier to scale and bugfix application in future and save time, but maybe it's more reasonable in my situation to wait few weeks till I have at least some skeleton architecture of my app and than once I am sure with it I can cover it with tests to have a solid base? And than continue with TDD and do all the tests with TDD.

share|improve this question
    
My answer is exactly the same as for a similar question programmers.stackexchange.com/questions/148329/… –  rosenfeld Mar 10 at 18:38

2 Answers 2

There is a difference between prototypes and code written with the goal to be run in production.

  • Prototypes are done to quickly test a concept. Code quality, security, maintainability don't matter. What matters is to finish the piece of software quickly in order to have the results (i.e. if the ideas behind are viable) as soon as possible.

  • Production code is expected to be more tested and more reliable, easy to maintain, secure, etc. If you sacrifice code quality, architecture or testing in order to accomplish the task quicker, it will hurt you sooner or later. In essence, not spending one hour testing your code now will cost you (or your colleagues) days later, because of a strange bug you could have caught easily if you were testing your code.

If your intent is to use the code later, write it as it was expected to live forever. Skip testing only if you know, for sure, that the code will be thrown away very soon (soon: in a few weeks).

share|improve this answer
    
Y2K was caused by people that 'knew' their code wouldn't still be running in 30-40 years. –  Sean McSomething Mar 15 '13 at 23:21
2  
I disagree with this idea of a prototype. Prototypes always end up as production code. Never compromise code quality, it will always bite you. –  Dave Hillier Mar 15 '13 at 23:32
1  
@Dave Hillier: Companies which find themselves with the code from prototypes in their production code should not force their developers to write high quality code for prototypes, but try to understand what went wrong and caused the code from a prototype to end up in production. –  MainMa Mar 16 '13 at 0:30

It is a trade off, however, in most cases the answer is, yes, you should use TDD (or BDD).

Studies show that TDD may cause a an increase in initial time to develop but reduction in number of defects outweighs this.

Detecting defects later on adds substantially to the cost of development. TDD gives you faster feedback and allows you to identify defects as close to writing the code as possible.

TDD also gives a number of other benefits (when applied correctly).

  • It encourages more loosely coupled code, as tightly coupled code is harder to test.
  • It highlights violations of SRP, as extra responsibilities add an extra dimension to the test meaning a combinatorial explosion in number of tests.
  • It facilitates pair programming, see Ping Pong Programming.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.