21–30 of 67 posts
Earlier quoted context omitted.
I suspect the linked article is a straw-man built to provoke responses, and thereby create page views for the blog.
I suspect your comment adds absolutely nothing to the conversation. If you disagree with the premise then how about explaining why you think TDD is the panacea for poor software quality.
This article misunderstands TDD completely. In TDD, the tests are your specifications . Therefore, any code that passes the tests is formally correct - even though it should always be minimal (YAGNI). In fact, TDD is not simply "tests first". It is: write ONE test, make it pass with the MINIMUM amount of code, refactor, loop.
Hence over time the codebase becomes this huge tangled mess of "formally correct solutions".
Earlier quoted context omitted.
I suspect the linked article is a straw-man built to provoke responses, and thereby create page views for the blog.
I (sadly) average 1 article written per 3 years, so there wouldn’t be much of a point in creating page views.
The title contains that "bold statement" to incite a response.
There are numerous fallacies in your article. I believe it's a misunderstanding of certain aspects.
> writing code in a test-driven way bypasses your brain and makes you not think properly about what you are doing.
You should not just start writing code blindly. You should have a clear understanding of the problem up front. When you start coding, it should be done after you have a plan.
> Furthermore, true 100% code coverage by tests is a myth: no matter how many good tests you write, not all cases will be covered.
Code coverage measures the code you've written tests for. It in no way promises to cover all cases. This is not a deficiency in code coverage, merely it's understanding.
> Therefore, mindlessly modifying code until all tests pass is likely to introduce new bugs for which no tests exist.
Ignoring the other parts of this that make no sense, I propose that mindlessly modifying code without tests will introduce bugs.
> Algorithms must be understood before being modified, and modifications must be done as if no tests exist at all.
I don't understand this. Of course they must be understood. TDD does not remove this requirement. I'm also not sure how modifications must be done as if no tests exist? Maybe you mean to suggest that optimizations in algorithms must be applied all at once, and cannot be made in small, incremental changes?
> You apply the optimisation, and some tests start failing.
Whereas if you did not have tests, you might not know this.
> But how can you be sure that the algorithm still works? How can you be sure that the mindless modifications did not introduce edge cases that were not tested before?
How can you be sure that your algorithm worked before in all cases? How can you be sure, without testing, that your changes still work?
You really are making a straw-man. You are effectively arguing that TDD doesn't prove something that TDD doesn't promise. In fact, your premise - "no matter which software development methods you use, do not forget to use your brain." - and your title imply clearly that TDD doesn't encourage using your brain.
That's most assuredly not true.
P.S. I hope I don't sound harsh. I'm not trying to belittle or insult you. =)
TDD is good for verifying that your code handles the set of requirements given by the customer - including any edge cases that matter to them. I probably agree that 100% test passes doesn't equal no bugs. Nonetheless, it's still useful! You can still write TD code and use your brain - it is only slightly easier to be lazy (and specifically, lazy in a way you're not supposed to care about, yet.) In the end, production…
> I probably agree that 100% test passes doesn't equal no bugs. TDD never promised that, and practitioners of TDD understand that 100% coverage doesn't mean you won't have bugs. This doesn't invalidate the TDD or testing (as you are obviously aware of =)).
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 ?
I think the problem mostly spans from the "do the simplest thing that could possibly work"[1] methodology that some practitioners of TDD advocate over thinking about the problem and solving it properly. [1] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...
The author made one slight mistake: he wrote "there is a tendency to mindlessly modify code" instead of " I have a tendency to mindlessly modify code". Also, it's not like this we haven't seen this kind of behavior decades before the invention of TDD. This is just another example of a craftsman blaming his tools. TDD is not a silver bullet, but no method or tool can serve as an excuse for mindlessly poking around unt…
One of the problems here is language: TDD as a general concept can cover everything from high-level behavioral testing to a method-by-method way to design your program. There's a big difference between those two!
In general, of course, programming is balancing what the program is supposed to do with how the program is constructed. That's true whether you have TDD in the mix or not.
The author made one slight mistake: he wrote "there is a tendency to mindlessly modify code" instead of " I have a tendency to mindlessly modify code". Also, it's not like this we haven't seen this kind of behavior decades before the invention of TDD. This is just another example of a craftsman blaming his tools. TDD is not a silver bullet, but no method or tool can serve as an excuse for mindlessly poking around unt…
I can't describe how shocked I was.
TDD in theory is a great idea. In practice it is dreadful. Because what has happened is that the obsession with code coverage has meant that developers create a whole raft of tests that serve no real purpose. Which due to TDD then gets translated into unworkable, unwieldy spaghetti like mess of code. Throw in IOC and UI testing e.g. Cucumber and very quickly the simplest feature takes 5x as long to develop and is bor…
Also, don't test stuff that isn't going to break, and avoid writing system and UI tests unless you absolutely have to.