I think an essential part of the red, green refactor cycle is at the refactor stage you should look at the test code too.
That's a good point, and I agree. But when you're refactoring application code, you can rely on the tests failing if you break something (if you have good tests). But if you break a test, it might not fail. Do you temporarily break the app code again to make sure the tests fail in the same way?
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 think an essential part of the red, green refactor cycle is at the refactor stage you should look at the test code too.
Too often people will happily refactor the production code (actually a lot of people ignore this too) but then leave the tests a mess.
Tests have a cost, as this article alludes. Therefore you should question them as you refactor and develop the system.
A simple question I ask myself when I am working in a particular test suite is
If I am confident, delete! Otherwise it has value, keep it.
Question the value of your tests and keep refactoring them
That's a good point, and I agree. But when you're refactoring application code, you can rely on the tests failing if you break something (if you have good tests). But if you break a test, it might not fail. Do you temporarily break the app code again to make sure the tests fail in the same way?