Given that almost all software engineering is refactoring legacy code (it's legacy as soon as it's shipped 😁), I think this is an excellent question! A question that generalises from 'are legacy tests still valuable?' to 'are any of our tests still valuable?', particularly given the balance to be struck between the value of tests and the cost of maintaining them (in time and stress).
I'd be interested to know how you go about checking that tests reflect business requirements (notoriously slippery things!), as I think this is the hardest part of the problem.
<opinion>
Personally, I like to think of testing being in one of two categories: internal tests (typically unit tests, integration tests) that provide the local team with the confidence that their code reflects an internal design; external tests (typically user-acceptance tests, contract tests) that provide consumers of the system with the confidence that it does what they expect. Given these two categories, I often suggest that internal tests are transient, that is: once they are passing, they can be retired / removed (remember they are still in the change history, be bold with the git rm commands!), leaving only external tests, which must be validated with customers/consumers on a regular basis: this offers opportunity to remove features that are no longer used and their tests..
</opinion>
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.
Given that almost all software engineering is refactoring legacy code (it's legacy as soon as it's shipped 😁), I think this is an excellent question! A question that generalises from 'are legacy tests still valuable?' to 'are any of our tests still valuable?', particularly given the balance to be struck between the value of tests and the cost of maintaining them (in time and stress).
I'd be interested to know how you go about checking that tests reflect business requirements (notoriously slippery things!), as I think this is the hardest part of the problem.
<opinion>
Personally, I like to think of testing being in one of two categories: internal tests (typically unit tests, integration tests) that provide the local team with the confidence that their code reflects an internal design; external tests (typically user-acceptance tests, contract tests) that provide consumers of the system with the confidence that it does what they expect. Given these two categories, I often suggest that internal tests are transient, that is: once they are passing, they can be retired / removed (remember they are still in the change history, be bold with the
git rmcommands!), leaving only external tests, which must be validated with customers/consumers on a regular basis: this offers opportunity to remove features that are no longer used and their tests..</opinion>