And yet ... millions of lines of code are written every day and tested the old fashioned way, and the world keeps spinning round and round.<p>Granted, every project can benefit greatly from unit tests. As for TDD, it is an admirable practice, but let's not get religious.
"It is unprofessional to release code that you are not sure if it will work or not. Know that it works."<p>The cost for making software that you know works, for the formal definition of "know"[1] is very, very high. That level of quality is usually reserved for space shuttles and similar.<p>TDD makes software as good as the tests you write. No more, no less. It can be a great aid in producing better code, and better tested code, but in the end all software development is a trade-off between time spent and quality. You have to decide where the line for "good enough" is. TDD itself doesn't magically move this line to "perfect" without incurring a corresponding cost in development time.<p>[1] A knows B iff B is true and A believes B and A has good reason to believe B.
<i>Only 40% does Test Driven Development (TDD)? It means that 60% of the developers don’t know if their code works or not!</i><p>First of all, 40% is way too high. Wonder what kinds of conferences they attend…<p>Also, even if you buy in totally to the agile premises, knowing whether your code works should be an effect of code coverage by unit tests, whether they're up-front or not isn't an issue at all.<p>And finally: No, we're not "professional". This is <i>Hacker</i> News.
"Be professional" would be a better aim.<p>In my opinion, the most important thing for code is for the developers to actually care about it. Whether you test first, test later, or just simplify the code until it's obviously correct [1] it really doesn't matter, just care enough to want bug free software.<p>[1] "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." (Tony Hoare)
> Only 40% does Test Driven Development (TDD)? It means that 60% of the developers don’t know if their code works or not!<p>What?! No. No, it doesn't mean that.
Some points:<p>- True TDD requires 100% test coverage of the code the developer using TDD has written or altered. I've seen the reports from companies or organizations claiming they do TDD that aim at least 60%. That isn't <i>true</i> TDD, in the Kent Beck definition of the term. That's not to say these people are wrong. In fact, because they have a better balance between test code and production code, they can change functionality of code more easily.<p>- Many developers attempting to practice TDD don't write the tests well enough to cover every possibly argument/configuration for the various methods they were testing. That's not TDD.<p>- Many developers attempting to practice TDD won't test trivial methods like getters and setters. That's not TDD.<p>- Many developers attempting to practice TDD write tests that duplicate the parts of the code being tested. While there are valid reasons for this, it results in frustration for the developer who needs to change 20 tests just to change one bit of functionality. Avoiding this in many cases can take an enormous amount of discipline and time, ensuring proper modularization, mocking, and refactorization of both production code and tests.<p>So, why do people claim to be doing TDD that aren't? Because there is not a good term out there that everyone knows of for just writing tests before writing code some of the time, duplicating functionality of tests, and leaving out functionality tested by many tests.<p>In some way, writing and maintaining tests is a lot like auto maintenance. TDD is like keeping your car in pristine condition. It is super-shiny because it is always just-washed and sparkly, and it runs like a champ. But in the end, the primary reason for the car is to get you from point A to point B.
Does anybody actually do Test Driven Development for the web? Looking through the stack of features and bugs I've run through in the last couple days, I can't find even <i>one</i> of them for which you could write a unit test.<p>- "Timeline ticks don't line up with grid when changing scale"<p>- "Resizing shapes is jerky in FireFox"<p>- "Need a button you can hit to pull up a simple Help screen"<p>- "Add an opacity slider for shapes"<p>Unit testing rendering correctness during mouse actions? Unit testing for UI features? Unit testing for CSS? Hacka please.<p>If you're doing little comp-sci type things on the server then sure you can do TDD. It makes sense in the context of building a string library or wrapping somebody else's API. In the web startup world though, how often are you actually doing that stuff?
Just a point - having tests in your code doesn't mean you're doing TDD.<p>Doing TDD - that is, writing tests up-front - forces you to not only consider the correctness criteria for your code (and gives you the confidence that the code, once written, works correctly), but it also forces you to design your code for test, which enforces separation between components (so that they're individually testable), generation of sane interfaces (so that simple mock objects can be written) and so forth. It's not just about making code that you can be confident in, it's about making saner code for the long term, too.
One word: Sudoku<p><a href="http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html" rel="nofollow">http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...</a>
Hi all, I am the author of the blog post.<p>It seems that the blog post got attention before it was correctly reviewed. Damn you guys are fast :-)<p>The idea was not to push TDD or promote it in any way. It was a rant to devs who don't do unit tests. Someone else needs to one day fix their untested code without knowing if changing something in X will break Z and Y.<p>Even the title of the post is changed now. Seems to be too late though.<p>By the way, your comments are great, they gave me many thoughts.
i'm working on legacy huge spagetty code with no option to write effective integration tests, testing that my method retuns some correct string/int etc will do me nothing, the whole system is huge with many integration points and no infra for writing integration tests and no time to do it. what should i do? (I love TDD, tests in general).