TDD is just a methodology, one of many, suited for some cases and not so much to others; some people feel comfortable with it and write better code because of it, others feel it awkward and cumbersome. TDD is not "the best". There are no recipe to write good code, just some guidelines and advices.
I think some aspects of TDD get too "personal", you can tell your employees what structure the code should have, deadlines, even format and style, but things like when to write the test, the order you make things, to me is too invasive, you are messing with the internal process of the programmer. Who cares if (s)he writes the test first or after, demand a proper test, trying to control the process is micromanaging and nobody appreciate that.
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.
and that is usually boring. :)
I like the idea βnot tested is just a mockup.β Similar to Michael Feathersβ definition of βlegacy code.β
Testing is a whole bag of tricks and just the mention of TDD can turn someone away from testing entirely, which is unfortunate.
TDD is just a methodology, one of many, suited for some cases and not so much to others; some people feel comfortable with it and write better code because of it, others feel it awkward and cumbersome. TDD is not "the best". There are no recipe to write good code, just some guidelines and advices.
I think some aspects of TDD get too "personal", you can tell your employees what structure the code should have, deadlines, even format and style, but things like when to write the test, the order you make things, to me is too invasive, you are messing with the internal process of the programmer. Who cares if (s)he writes the test first or after, demand a proper test, trying to control the process is micromanaging and nobody appreciate that.