Hacker News new | past | comments | ask | show | jobs | submit login

It seems a lot of these discussions surrounding testing are very anecdotal; this link being a prime example. I remember hearing an interview with Greg Wilson regarding his book Making Software, [1] the premise of which is to apply a more rigorous methodology to understanding what makes software work.

If I remember correctly from the interview (I think it is here[2]), one conclusion was that TDD doesn't have a clear benefit when you add it to a project. On the other hand, in a survey, TDD projects are more likely to succeed because it is a habit common to good developers. I hope I am capturing the subtlety there. Essentially, TDD is not a silver bullet, but rather a good habit shared by many good developers. That was enough to convince me of the merits.

It's another problem altogether to try to institute TDD for a project, especially for a team. Like so many things in programming, TDD could be used and abused. The same could be said for JavaScript or [insert proper noun here]. If misunderstood or used incorrectly, TDD could be a drain on the project. A benefit--and this ties back into the idea of TDD as a habit--is that it forces the code you write to have at least one other client. This requirement would alter the way you write code and arguably for the better.

[1] http://shop.oreilly.com/product/9780596808303.do

[2] https://blog.stackoverflow.com/2011/06/se-podcast-09/

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact