Even if this is sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter. Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it is really counter productive. I feel that sometimes people also take the rules to litterally without thinking about why the rules exist and when they make sense. I have seen code where the modularization is taken to such an extreme, that the end results is gazillion interfaces and levels that are never used at the end, making the code less readable. In general I think people need to be more critical of any new paradigm :-). So to me, pieces like this help to think about what we are doing and why :-).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Even if this is sarcasm, I think there is a point to some of it :-).
I have seen teams where the TDD is so extreme that people would write tests just because one has to write tests (because otherwise the code metrics would not pass), instead of focusing on the tests that matter. Because at the end, all these tests don't help if the most important tests are missing, plus it adds so much overhead (tests have to be maintained), that it is really counter productive. I feel that sometimes people also take the rules to litterally without thinking about why the rules exist and when they make sense. I have seen code where the modularization is taken to such an extreme, that the end results is gazillion interfaces and levels that are never used at the end, making the code less readable. In general I think people need to be more critical of any new paradigm :-). So to me, pieces like this help to think about what we are doing and why :-).