Ooops, I guess I missed the part where he said "in tests". That makes it a bit better, although when it triggers, it'll still need someone to triage why the test failed and either nudge the date up / delete the test / do the refactor. While that's going on, potentially you'll miss other failed tests because your overall build is red, or maybe you'll force someone to backout their change for no reason and stop other checking in that day. I actually worked at a place where if the build ever went red, all commits since the last successful build had to be backed out and nobody was allowed to check in again until the build was green again. This sounds drastic, but having lived with it for a couple of years, it grew on me - it stopped the repeated "Oh, that's just a one-line fix" that then broke something else and so on... Better to immediately revert the change and re-commit when you're sure everything will work. We also disabled and/or removed tests that will intermittently fail due to a fault in the test, and created an issue to write a better test if it was still relevant. The GP's test would have just deleted when it was discovered, rather than achieving its aim of getting someone else to do the refactor.

The best approach is still to do the refactor straight away if it's genuinely needed, or else create a task in your issue tracker to do it a later time if it's going to require resource that you don't have right now. Then PM can prioritise it accordingly, not have to react to an arbitrary timebomb placed in the code, which will invariably be discovered at a time that's not good for anyone.