> Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes.

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?

Tests might make you personally feel safer making changes but they are not Agile(tm) because they attempt to predict needs instead solving an explicit existing need. They violate YAGNI and worse there is work in removing and rewriting old tests.

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?

I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.

For unit testing, I suggest starting with parsers, or any string-parsing code you have. They tend to be nicely self-contained and have lots of edge cases that you can test in a data-driven way, using a loop.

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.

Depends on how you define a unit and what you're willing to mock. I treat a 'unit' as a piece of functionality. So one method on an API is a unit. if it does complex stuff then there may be more targeted tests down below. and depending on what sort of work it does i may not bother with unit tests because mocking a DB transaction isn't worth it.

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.

You say you've never understood the benefit of unit tests but you list three really great things: they help you debug stuff while you're writing it, they help you understand what you're writing and the edge cases, and they help others understand your code later. That's all great stuff.

The benefit is being able to make changes and sleep soundly at night.

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.

you have a lot to unlearn, young padawan. you must first forget what you know ...