I'm also not a fundamentalist when it comes to TDD. It really depends on "What can go wrong?" and "How much time does each route costs?"
The other day I showed the guy I'm mentoring how to write tests in go to test some Go middleware code for HTTP BasicAuth. This was some example code he found on the internet. And guess what, it has a basic logic flaw where it doesn't test for correctness of user AND password, but for correctness of user OR password.
Using code like this and not writing tests is really stupid.
When I was in university, I also read lots of papers on TDD. There are many "we had 20 students trying to solve a 2 hour problem with and without TDD"-papers and only a few "IBM and Microsoft used TDD and no TDD to write hardware drivers, these are the results" papers. Guess who I'm trusting more.
I remember when those papers were hitting headlines. The opinion of anti-TDDs back then was : "yes, it's certainly a good thing for students learning how to code", following the idea that it forced them to consider architecture rather than jumping on adding lines of code, and that experienced developers don't need it as much (thus, the conclusion was that those studies were biased toward people learning to code).
The answer of pro-TDDs was that you always benefit it, even when already experienced. I agreed with them, back then.
I don't remember seeing those about IBM and Microsoft, though. What were their conclusions?
Nowadays, I do what I jokingly call "documentation driven development", as a follow up for "top down development" that cucumber and the likes introduced. I'll usually first write about the problem I'm solving, then generally write about how I solve it, then write about components needed to implement that solution, then what those components do in details, then I write function signatures, and I stop there. I give it a month going back to it from time to time and I always figure out problems with it.
Refactoring that is awesome : no tests to change, no application code to change, it's just manipulating pure architecture, and it's incredibly fast to change while still being able to keep everything in mind. Careful planning is kind of replacing for me what TDD used to do (for the part about designing proper architecture ; I do integration testing for the part about catching regressions).
But really, I feel today that the methodology doesn't matter much : agile or not, TDD or not, this or that, whatever. What matters the most is people. The same methodology will have opposite results depending on who is applying it. I guess some methodologies will be better than others for learning programming, but I have really no clue how to measure that :)
I'm also not a fundamentalist when it comes to TDD. It really depends on "What can go wrong?" and "How much time does each route costs?"
The other day I showed the guy I'm mentoring how to write tests in go to test some Go middleware code for HTTP BasicAuth. This was some example code he found on the internet. And guess what, it has a basic logic flaw where it doesn't test for correctness of user AND password, but for correctness of user OR password.
Using code like this and not writing tests is really stupid.
When I was in university, I also read lots of papers on TDD. There are many "we had 20 students trying to solve a 2 hour problem with and without TDD"-papers and only a few "IBM and Microsoft used TDD and no TDD to write hardware drivers, these are the results" papers. Guess who I'm trusting more.