Quick and Dirty tests, FTW

If we consider solely the refactoring phase: Then what do we care about in tests. What quality do the tests need to be useful to us?

Imagine we could change the tests later, what do we actually care about during the hours/days we're performing some larger refactoring

It turns out we can do quite a few compromises, a lot of the vital qualities of a tests don't matter over a few days, running on a laptop with no other persons reading the tests

Now why would one want to write unmaintainable tests only to replace them later? Well for one it's a lot faster, secondly writing great tests for legacy code is often close to impossible. Given that we'll modify/replace anyway, the question is "What compromises can we make?"

This type of quick-and-dirty tests is precisely the kind of tests were likely to do in a 3P (Protect-Prepare-Produce) approach. The above post will also somewhat lay out when/how/what to do with those quick and dirty tests later.

What about you, are you doing these compromises. Any other compromises?