I don't recall ever reading that just because you have tests, you should no longer understand the processes by which your code functions. Was this something that they've seen happen, or experienced personally?
More importantly, I have also seen this happen in professional environments. A very large test suite is very useful, but it is absolutely not a catch-all safety net.
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. =)
Why do some people always assume bait/trolling when no such thing appears even remotely possible (as is this case, which is a well reasoned and argued post), is beyond be.
You might disagree with the author, but we tries and provides arguments for what he writes.