61–67 of 67 posts
[1] http://pragprog.com/the-pragmatic-programmer/extracts/coinci...
Contrary to this article, one great reason is that TDD/BDD allows me to make refactors and major changes and know whether or not I broke something. I find it passe to have the opinion of this article.
A perfect example for TDD/BDD is a complex REST API with dozen of end-points and refactoring a piece of the authentication system. How do I know if I broke something or introduced a bug?
My experience is that most developers do not test and this is exactly the kind of way complex bugs get introduced. You actually make the job more difficult on yourself because instead of knowing YOU broke something, a bug gets introduced and you spend more time tracing the cause. I have worked at many places that have this obnoxious cycle of deploying, breaking, deploying, breaking.
It is irritating to see articles like this pop up because it's not like it's a school of thought or a religion. It's a purposeful tool that can and will save you time and effort and probably impose a few good design practices along the way. I'm not saying shoot for 100% coverage, fuck, I'm happy just knowing a few complex pieces are working. And I don't always think it's a good idea to design API's from the tests, especially when you are experimenting and researching.
I've been mixing in TDD and BDD for the last 1.5 years of my 11 year coding career. I can't think of any reason not to test except for laziness and someone's unwillingness to truly use their brain to evaluate it's value. Contrary to this article, one great reason is that TDD/BDD allows me to make refactors and major changes and know whether or not I broke something. I find it passe to have the opinion of this article…
I've been mixing in TDD and BDD for the last 1.5 years of my 11 year coding career. I can't think of any reason not to test except for laziness and someone's unwillingness to truly use their brain to evaluate it's value. Contrary to this article, one great reason is that TDD/BDD allows me to make refactors and major changes and know whether or not I broke something. I find it passe to have the opinion of this article…
Your "perfect example for TDD/BDD" is actually about testing in general, not TDD. You are stating the value of having a test suite when making a large change, not the value of writing tests first.
Earlier quoted context omitted.
Sure you will still have bugs. The question is whether the reduction in bugs due to TDD outweighs the increased investment in developer and tester time. Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it. Not to mention the detrimental impact on build times. All of that aside. Have you noticed how there are no decent metrics available for TDD's effectiveness ?
> Because for those of us who do TDD every day the blowout in time is at minimum 2-3x longer than without it. I do not know your environment, but TDD does not add 2-3x longer for most everyone I know that practice it. This is especially true when you factor in total development time. Most estimates I see place TDD making the project take 15-30% longer. > All of that aside. Have you noticed how there are no decent met…
I see that claim a lot, but when I look at the "studies" being cited, they rarely stand up to even cursory scrutiny about their methodology and the choice of test subjects.
These studies (or those making a case for TDD based on them) tend to do things like generalising results based on a few undergraduate students writing toy programs to draw conclusions about professional software developers working on industrial-scale applications, or using no unit testing at all as a control rather than say doing either test-first or test-last unit testing but not following the TDD process.
If you have better sources, please do share them. Developing a non-trivial application using two different techniques is rarely cost-effective, even without controlling for having different developers or experience in the two cases, so getting good quality data about the effectiveness of software engineering processes is hard.
I would add to this that algorithms must be understood before being tested, something with which I suspect most TDD proponents would agree, and which would dispense with the need for the rest of the article.
Earlier quoted context omitted.
Usually this makes people go for very simple solutions without thinking properly what are the right data structures and algorithms for the problem at hand. I rather write proper designed code and write the tests afterwards, before delivering the code.
True, however the solution is ok since passing the test is the only quality you need. If not, write a new test, make it pass. The naive implementation can be substituted with a different one easily since the tests guarantee correctness. Generally though, since the "third leg" of TDD is refactoring, this ensures that the proper structures are going to be used in place as soon as they are actually needed.