11–20 of 42 posts
I'm a bit confused why this article was written in a satirical (sarcastic?) style. It raises a lot of good points, but it would have been much more straightforward if it hadn't been written sarcastically. All of the points in the article could have been written from the position that the author ACTUALLY advocates, which would have made it more readable without sacrificing any content.
It seems to me the author is such a proponent of TDD that the idea of not using it is laughable. The humor is so dry that it almost seems like a serious article. I got a few laughs though.
I'm a strong proponent of TDD. In my experience its more productive, and results in better software. But.... I've been in this position before: We have a large existing codebase with no unit tests to speak of, and the business is not willing to fund efforts to refactor or add unit tests. It is very hard to add unit tests after the fact. Not impossible, but its alot of work, and business folks really don't care.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development?
My view is that in a complex system, only by having confidence in the units can you have confidence in the integrated whole.
You might be able to build a house that stands and looks nice, but if the timbers, the bricks, the foundations etc are all flawed in their own small ways, sooner or later those problems are going to combine and you will end up squashed.
I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Even the hackiest throwaway script could likely be produced faster and easier with a little automated driver.
I'm a strong proponent of TDD. In my experience its more productive, and results in better software. But.... I've been in this position before: We have a large existing codebase with no unit tests to speak of, and the business is not willing to fund efforts to refactor or add unit tests. It is very hard to add unit tests after the fact. Not impossible, but its alot of work, and business folks really don't care.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ
Bottom line is that writing TDD style unit tests won't make crap code better any more than removing them makes good code worse. TDD is a tool, nothing more, nothing less.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Could you expand on this? Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development? My view is that in a complex system, only by having confidence in the units can you have confidence in the integrated whole. You might be able to build a house that stands and looks nice, but if the timbers, the bricks, the foundations etc are all flawed in their ow…
Not engaging with the above argument, just trying to clarify an ambiguity. Just saying (and trying hard to keep tone neutral).
automated testing != test driven development.
The former has been in use for decades. The latter is a relatively new methodology/practice which emphasizes writing tests first and using tests to drive development.
And it belittles some of the complicated arguments such as: If you develop to the test, the test will always pass— but that doesn't mean that your software is any good. Loosely coupled development and testing can result in the tests being more powerful proxies for overall quality.
I'm a strong proponent of TDD. In my experience its more productive, and results in better software. But.... I've been in this position before: We have a large existing codebase with no unit tests to speak of, and the business is not willing to fund efforts to refactor or add unit tests. It is very hard to add unit tests after the fact. Not impossible, but its alot of work, and business folks really don't care.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap c…