I totally agree. Code coverage is only as good as the tests themselves. I have always written tests for failures first, then a test that should pass given correct inputs. If you do not write tests that force a failure, you are only batting 500. And when your company's reputation is riding on proper code, 500 isnt a good number.
TDDing by implementing the failure behaviour first is also an excellent way to think through all the ways things could go wrong. As you say, our companies reputation -and revenue- depend on the software not letting the users down accounting for as many failure paths as possible is the way to go.
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.
I totally agree. Code coverage is only as good as the tests themselves. I have always written tests for failures first, then a test that should pass given correct inputs. If you do not write tests that force a failure, you are only batting 500. And when your company's reputation is riding on proper code, 500 isnt a good number.
True.
TDDing by implementing the failure behaviour first is also an excellent way to think through all the ways things could go wrong. As you say, our companies reputation -and revenue- depend on the software not letting the users down accounting for as many failure paths as possible is the way to go.