3 ms·

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a y

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a year ago and learned with TDD as part of how I build almost every project. Although I think it's always the case that I might "be doing it wrong", it's hard for me to imagine now writing code without first writing tests. Part of this is, admittedly, that I'm still uncertain if my solutions or code will even work and writing tests helps me to both organize what I want to do and also verify that I haven't made silly syntax mistakes. Was it harder to learn this way? Absolutely (at least I think so, but my sample size is 1). I can't tell you the state of despondency I was sometimes in learning test suites and trying to figure out how to test certain things all while knowing that I could just write the stupid code and inspect the output to see if it was right. Also, I love to refactor. How do you refactor if you don't have tests to catch you when you break something?

PaulKeeble 9y ago
You don't refactor if you don't have tests, or rather you do and you break stuff and take on a lot of risk. The reality is a lot of developers aren't working in teams with others and working on software that has a long future ahead of it, hacker news tends towards the smaller teams with short runways and its write it and throw it away as a strategy rather than refactoring.
draw_down 9y ago
Not doing TDD doesn't mean not having tests! As far as the beginner angle, it makes sense to me to stick to TDD when learning to code. There are already so many things to learn and understand, that sticking to one way of working would likely be helpful. The question for me would be whether it matters whether that method is TDD or something else; I suspect it wouldn't matter much.
oelmekki 9y ago
Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, although automated testing somewhat got very popular only a few years before TDD). I too became a big fan of TDD when I was introduced to it by rspec, then a brand new testing tool. But those latest years, I grew tired of keeping fixing my tests despite having no regression in my codebase - just because implementation changed. I quit doing TDD, but mainly because I quit doing unit testing. Nowadays, I only do integration testing. I've made a chrome devtool extension to generate capybara tests while I'm browsing, so that I can write my feature, then generate a test for it while doing visual QA in literally 5 minutes (this was something selenium IDE was doing in its time, I just made something a bit more modern to replace it). And since this is integration testing, my test won't break as often if I change the underlying implementation to do the same thing. I would even argue it makes my refactoring more pleasant : if I refactor correctly and end result is not altered, I don't even have to edit my tests (if it breaks, it may actually be a regression). That being said, what matters is what makes you more productive. Don't take our word for it, it may not apply to you. Just keep wondering how you could make things better.

PaulKeeble 9y ago

You don't refactor if you don't have tests, or rather you do and you break stuff and take on a lot of risk. The reality is a lot of developers aren't working in teams with others and working on software that has a long future ahead of it, hacker news tends towards the smaller teams with short runways and its write it and throw it away as a strategy rather than refactoring.

draw_down 9y ago

Not doing TDD doesn't mean not having tests! As far as the beginner angle, it makes sense to me to stick to TDD when learning to code. There are already so many things to learn and understand, that sticking to one way of working would likely be helpful. The question for me would be whether it matters whether that method is TDD or something else; I suspect it wouldn't matter much.

oelmekki 9y ago

Not doing TDD does not mean not having tests, it just means writing them after writing the feature (this has been the usual way for a long time before TDD, although automated testing somewhat got very popular only a few years before TDD). I too became a big fan of TDD when I was introduced to it by rspec, then a brand new testing tool. But those latest years, I grew tired of keeping fixing my tests despite having no regression in my codebase - just because implementation changed. I quit doing TDD, but mainly because I quit doing unit testing. Nowadays, I only do integration testing. I've made a chrome devtool extension to generate capybara tests while I'm browsing, so that I can write my feature, then generate a test for it while doing visual QA in literally 5 minutes (this was something selenium IDE was doing in its time, I just made something a bit more modern to replace it). And since this is integration testing, my test won't break as often if I change the underlying implementation to do the same thing. I would even argue it makes my refactoring more pleasant : if I refactor correctly and end result is not altered, I don't even have to edit my tests (if it breaks, it may actually be a regression). That being said, what matters is what makes you more productive. Don't take our word for it, it may not apply to you. Just keep wondering how you could make things better.