Recently I began a new project to re-implement a core part of automation. Since it is very important, I'm TDDing it so that I can tests various basic scenarios as well as things we know the old system doesn't do.
In doing this, I find myself creating a few "sandbox" tests, which exercise "candidate" algorithms in complete isolation so I can choose the one that best meets requirements. I've also created some tests to figure out why other tests are failing, which again are coded in a "sandbox" manner and don't test actual production code (they instead have a simplification of the production environment that I can alter until I find the problem/cause/solution). Neither of these has continuing value for regression; once I pick an algorithm I may never use the others, and once a test shows why another test is failing, I can correct the initial test (or its exercised production code) and verify correctness, and I no longer care that the other test's hard-coded exercise environment still fails.
When learning TDD I was taught that you NEVER delete a unit test; even if the test's original purpose has become irrelevant, the code within the test can be of use to other developers as a model, or the test can be refactored for some other purpose later. Instead, if a test has become redundant or irrelevant and should no longer be run, pass or fail, it should be ignored.
Is this the "generally-accepted" stance on ignoring tests? Does this have the potential for abuse (e.g. "I don't think it matters anymore, and it fails, so I'll just ignore it")?