I see absolutely nothing in the Agile Manifesto that precludes tests. Nor do I see any basis for saying that tests attempt to predict needs. They are for the future, true, but they're also for the present - as is every line of code you write.
>Nor do I see any basis for saying that tests attempt to predict needs
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.
> The prediction is that the next time you revisit this code your original assumptions will still be valid.
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?
