5 ms·
This argument is not sound at all. The statefulness of your code has nothing to do with why we write unit tests. Even if you write a purely stateless function,
by dusklight 17y ago
This argument is not sound at all. The statefulness of your code has nothing to do with why we write unit tests. Even if you write a purely stateless function, it would still be useful to write a unit test to check for correctness. If you are doing TDD, you wrote the test before you wrote the function and that way you know exactly when you are done (because the test now passes). If you wrote your test afterwards, it is still useful if you ever change the behavior of the function, because any unit tests that were written that use this function will now let you know where and in what manner your change has affected the entire code base.
If you are writing bad stateful code that has a lot of bugs and you are not smart enough to figure out how all the states interact, unit tests will help you a lot, but there are many other scenarios where unit testing is useful.
I would not say good code has few unit tests. I say arrogant code has few unit tests. If you write few unit tests, as the size of the codebase grows, you have increasingly less certainty about how any change to the existing codebase will affect other parts. When the codebase is small, this is not a problem. If you are very intelligent, the size of the codebase that you can manage in your head might be quite large. But you are just wasting mental capacity that might have been doing so many more interesting things if you didn't have to remember everything and could trust your unit tests to give you the information you need when you need it.
- jhancock 17y agoI'm not completely against TDD. However, one thing I've found is bugs are caused by things you didn't think to write a test for (or write your code to handle sans tests). The mundane stuff I see in the vast majority of unit tests are things an experienced programmer almost never screws up. So how do you write a test for a case you couldn't foresee? My biggest argument in favor of writing tests is to ensure my code doesn't break relative to other people's code. There are many times I've encountered an update to a ruby gem with no major or minor version change that has broken a, usually implied, contract with my code. I say implied, because duck typers, at least what I've seen in the ruby world, tend to be slack about formalizing interfaces. I write tests to protect against that sort of thing.
- youngian 17y agoSo how do you write a test for a case you couldn't foresee? You don't, but once you discover it, you write a regression test to make sure it doesn't come back. However, IANATDD, I am not a test-driven developer - I don't see any reason to be dogmatic, but I do think unit tests can be extremely valuable. So this answer might not be TDD-approved.
- InclinedPlane 17y ago"So how do you write a test for a case you couldn't foresee?" "You don't, but once you discover it, you write a regression test to make sure it doesn't come back." Sure, that's SOP in any good dev. house that does testing. But you've failed to address a key weakness in TDD. The real question is how do you discover these sorts of defects given that a single developer writing in a TDD style is unlikely to do so? TDD is clearly not a cure all, and this is a major weakness of it. Other development techniques, many of which can complement TDD, such as formal code reviews and beta testing can do a better job of getting you to higher product quality than TDD alone.
- chuckm 17y ago"TDD is clearly not a cure all" Who said it was?
- eru 17y ago> Even if you write a purely stateless function, it would still be useful to write a unit test to check for correctness. Indeed. Tests are a good idea in, say, Haskell, too.
- moss 17y agoI think I'm blithely misreading the article here, but I'm inclined to take it as advice about how to do TDD, rather than an argument against it. Specifically: if a class has lots of tests, this is a sign that the class is too complicated. Refactor until it is simple enough not to require as many tests (possibly by narrowing its interface, possibly by breaking it up into multiple classes, possibly by rethinking how it's implemented).
- allyt 17y agoFrom what I know, Andrey (the poster) is pretty neutral on TD, maybe even a proponent. He's saying you should have an interface in mind when you start to write unit tests. Sometimes you can do that before writing code. Other times, exploring with a REPL first is better.