The prediction is that the next time you revisit this code your original assumptions will still be valid. In games, which is my background, game rules (our business logic) are constantly changing during development to the point that you're fighting tests constantly for no benefit. Games are an extreme case but you can extrapolate the experience.
You've already admitted that there is a point when tests are not worthwhile when you are iterating. My argument is simply that in my experience you're in that state more often than not. Ultimately user value is the only thing that matters and tests don't predict that.
And I'm not saying you're not allowed to write tests. If something helps you do it. I'm arguing against code coverage and test enforcement.
No. The tests will encode the previous assumptions. When you run them, and they fail, either you broke something or one of the previous assumptions is no longer valid. But the tests give you an automated way of recognizing which assumptions you'd better think about, to see if they are still valid.
> Games are an extreme case but you can extrapolate the experience.
No - no more than you can extrapolate my experience, which is having core logic that is (mostly) valid a decade later.
> I'm arguing against code coverage and test enforcement.
Or at least against those things in areas that are constantly changing. Even in your world, though, are there areas that change more slowly than the game rules? Would it make sense to have tests for those areas, and not for the game rules?
Strongly disagree. Tests empower agile.
Here's a module/class/object/file. The unit tests test the externally visible behaviors of that code. Now stuff happens; the code needs to change. That's OK, we're agile, we can deal with it. I make the changes.
What did I break? I run the existing tests. Some break. Is that because the test doesn't reflect the new changes? I fix those tests. Or is it because I broke something? Good to know that early. I fix my code.
Next question: Did my changes do what they needed to do? For that, I write new tests.
Finding your problems early is a big part of agile. Tests are a big part of finding your problems early.
Now: If you're prototyping a new algorithm, would I write detailed unit tests before it gels? Probably not. (In XP, we called this a "spike" - trying to nail something down, not necessarily writing production code.) But even then, how do you know that your algorithm does what you need it to do? Maybe some tests?