4 ms·

I've seen far more problems from people who think they understand the code so they don't need tests than from people who write tests to check their code. The be

I've seen far more problems from people who think they understand the code so they don't need tests than from people who write tests to check their code. The best of the best might be able to get by without tests, but us common-folk stand to benefit a lot from writing tests and listening to the design feedback they provide.

jeremiep 11y ago
While I agree with the general idea in theory, I haven't seen it happen that often in practice. More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it. People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is. I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door. Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory! I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.
- munificent 11y ago
  Sounds like a lot of projects you worked on had tests at the wrong granularity. Fine grained unit tests are good for helping you find out where a bug is in the code, at the expense of calcifying your architecture. "Functional", "integration", "end-to-end" or other higher level tests don't pinpoint a bug as easily but in return they give you greater freedom to reorganize your implementation. For example, I work on a code formatter: https://github.com/dart-lang/dart_style https://github.com/dart-lang/dart_style It has a metric ton of tests, which is absolutely critical for ensuring a change to one corner of the formatting doesn't regress other things. Formatting is solving a bunch of global constraints, so almost every change interacts with other things. I've rewritten almost the whole thing twice at this point, and the tests never slowed me down. That's because they're functional tests: they just run the formatter and validate the expected output. It does mean I spent a hell of a lot more time figuring out why some test was failing, but it made refactoring a joy.

jeremiep 11y ago

While I agree with the general idea in theory, I haven't seen it happen that often in practice. More often than not tests will constrain the architecture of the actual system and result in code that is much more complex than what is required to solve the problem at hand. People then start having blind faith in their tests while being completely oblivious to what they don't test. At that point the codebase is such a mess that you do need tests to maintain it. People who focus on understanding their code work very, very hard to keep their codebase simple enough to quickly wrap their heads around it. I know I modify my codebase way too much for it to have tests - I'd spend more time refactoring the tests than progressing and I wouldn't be able to simplify the architecture as much because my attention is now on how testable the code is rather than how simple it is. I see projects shipped with unittests that still required maintenance and debugging 6 months down the road, and others without tests that worked flawlessly out the door. Of course, there's a difference between understanding and thinking you understand, but that's another matter entirely as we're walking into Dunning-Kruger territory! I'm not saying tests are bad! Far from it, I do write tests for functions where the logic isn't obvious, but my point is that there's too much focus on testing and not enough on actual quality and simplicity.

munificent 11y ago
Sounds like a lot of projects you worked on had tests at the wrong granularity. Fine grained unit tests are good for helping you find out where a bug is in the code, at the expense of calcifying your architecture. "Functional", "integration", "end-to-end" or other higher level tests don't pinpoint a bug as easily but in return they give you greater freedom to reorganize your implementation. For example, I work on a code formatter: https://github.com/dart-lang/dart_style https://github.com/dart-lang/dart_style It has a metric ton of tests, which is absolutely critical for ensuring a change to one corner of the formatting doesn't regress other things. Formatting is solving a bunch of global constraints, so almost every change interacts with other things. I've rewritten almost the whole thing twice at this point, and the tests never slowed me down. That's because they're functional tests: they just run the formatter and validate the expected output. It does mean I spent a hell of a lot more time figuring out why some test was failing, but it made refactoring a joy.