The problem with "best practice" is that your work is always an exception.
Other answers have suggested methods of turning tests on automatically when the code is fixed. That is far better than hoping that somebody turns it on when the code is fixed, but
- how do you report the non-running test in this case ?
- does the test/bug end up in release notes ?
We are perhaps lucky in that developers and testers work together and there is normally somebody to do an ad hoc investigation.
We add excuses to the test script.
- The tests still fail and are in statistics
- The excuse is presented at the top level
- Analysis (verifying that the failure matches the excuse) is straightforward
Doomed Tests (won't be fixed for 'a long time') are kept running
- With an excuse of course
- If there are multiple tests with the same failure, we tend to reduce down to an exemplar, or shove the rest to the end of the campaign so that they are skipped.
You will notice from the above that the tests are not fully automatic.
We operate a number of different test campaigns. The sanity and regression campaigns only ever gets tests that are proven to be reliable. That should mean that failures such as described here, never make it into those campaigns...
...so we can still run fully automated tests to prove that the build hasn't been broken.