How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At best you could make some integration tests but that is not the same thing.
I also think there are better practices than tests to keep iteration pain low but that doesn't preclude tests so I guess that's not an argument against them. That said I prefer to focus on making composable, low side effect code than write more tests.
Personally I hate tests although I come from games where you need human QA testers to test that your game feels fun anyway so I do admit that's a unique situation.
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?
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?
Even if you're just using a regular expression for parsing, it can be worth moving the parsing code to its own function and testing it like a parser.
In java land when I'm writing stuff i use unit tests mostly as a place where i can run code without having to compile the whole app. And any tests that come out of it just end up being a bit of regression protection.
But there's always a bigger slightly more complex unit test i write which tests the bigger unit of function. And those really straddle the line between unit and integration testing but i find i get the most value from them because one you lock in and publish functionality you have a contract you have to honor.
I agree with the grandparent that they are more useful as a project matures rather than the design stage. Starting small and adding tests as designs solidify is a good tradeoff.