> I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?

That's the main reason we have this discussion in the first place IMO. There is no one right answer to the question.

>I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?

I find it really depends on the level of nuance required of the final behavior. Maybe the test suite doesn't cover certain implicit requirements of the software, often a bug becomes a feature without anybody noticing in sufficiently old projects.

Likewise the tests might not even be structured in a way that's conducive to a rewrite, depending on their level of specificity. Maybe you only care about the final, black box behavior and individual unit tests should be thrown out so you don't need to adhere to existing function I/O requirements.

It just depends. Like you said, very contextual.

I've made a career out of bashing half-baked code into shape, or dragging legacy code to meet new needs. You have tests? You can be much more confident about where you're going. Usually the first thing I do when dealing with code is write some tests to capture how it behaves now, before making any changes.

> Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?

Depends how much you trust your test coverage.