4 ms·

I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. To me, keeping code simple and easy to rea

I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. To me, keeping code simple and easy to reason about is what yields reliable software. If you can't wrap your head around something in the first place then tests are only going to give you the illusion of reliability. Its as Rich Hickey put it: "What does every bug have in common? They all passed the type checker and the tests!"

Cacti 10y ago
As the saying goes, crap in, crap out. It's just as easy to write crappy unit tests as it is crappy code.
- tmm 10y ago
  Or, as W. E. Deming wrote: "You cannot inspect quality into a product."
- finishingmove 10y ago
  And it's extremely hard to write unit tests for crappy code.
  - Cacti 10y ago
    Extremely hard to write _good_ unit tests for crappy code.
- danudey 10y ago
  After three years of working on some software (basically some fancy shell scripting but in Python), when the project had grown dramatically beyond its original scope through a host of hacks and bolted-on features, I remembered that the software had unit tests and ran them. Surprisingly, all the unit tests passed, and my first thought when I saw that was "Man, I bet these unit tests are awful."
mathgeek 10y ago
> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I'm inclined to think this could be generalized to those who are most obsessed about any specific practice.
- thenewregiment 10y ago
  Absolutely. The majority of the programming world is obviously dumb. You are the true master.
- ams6110 10y ago
  A very non-PC joke from George Carlin springs to mind...
pmarreck 10y ago
> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I don't think you can generalize this, neither subjectively (my shipping code quality has gone way up since I switched to TDD) nor empirically (evidence seems to indicate that you can achieve up to a 90% production bug reduction with a 15-35% upfront extra time cost doing TDD, which most would consider "worth it"). Secondly, this doesn't mean a very good programmer on a team doesn't have to write tests, if only to prevent others from breaking the behavior expectations of his code down the line. Thirdly, tests serve to validate that behavior if you yourself ever have to go back to the code to change or refactor it, so unless you are SO good of a programmer that you have perfect memory of the mental models of all your past code (which would put you in the extreme minority of all programmers), they will still come in handy.
- jeremiep 10y ago
  Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture prematurely. More often than not I see TDD yielding horrible, terrible software architectures and at that point you do need tests to maintain the resulting mess. TDD somehow assumes emergent architectures and I know from experience this is the worst way to architect something. NPM for example is full of well-tested libraries with poor architecture and bad usability (could be why everything is reinvented every 6 months) but I wouldn't call that a success story. I'm willing to bet the bug reduction from the extra time upfront doesn't come from doing TDD but actually thinking about the requirements and how they fit the larger picture. I really like the following story to illustrate this point: http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...
  - pmarreck 10y ago
    That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)
entee 10y ago
I think unit tests are a great tool to motivate code that is simple and easy to reason about. After all, a good unit test is itself simple and easy to reason about. It also forces you to think about what is the simplest unit of software for a given task, helping design the software it is testing. Also, I've definitely had code I thought was well tested and good to go, but when I rigorously went back and wrote unit tests, I found subtle bugs I wouldn't otherwise have known to fix. That said, yeah it's not all it takes to get things right. Dogma is bad, but unit tests are an essential part of the toolkit for ensuring code quality.
- kedean 10y ago
  Yeah, i've found that my heavily unit tested code is often my best code, simply because designing it with that in mind yields the simplest, smallest units. If I know I'm gonna need to write a unit test later, I'm much more inclined to split a long function out into more sensible small ones, and I'm not going to try to combine two different behaviors (because that's hell to test).

Cacti 10y ago

As the saying goes, crap in, crap out. It's just as easy to write crappy unit tests as it is crappy code.

tmm 10y ago
Or, as W. E. Deming wrote: "You cannot inspect quality into a product."
finishingmove 10y ago
And it's extremely hard to write unit tests for crappy code.
- Cacti 10y ago
  Extremely hard to write _good_ unit tests for crappy code.
danudey 10y ago
After three years of working on some software (basically some fancy shell scripting but in Python), when the project had grown dramatically beyond its original scope through a host of hacks and bolted-on features, I remembered that the software had unit tests and ran them. Surprisingly, all the unit tests passed, and my first thought when I saw that was "Man, I bet these unit tests are awful."

mathgeek 10y ago

> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I'm inclined to think this could be generalized to those who are most obsessed about any specific practice.

thenewregiment 10y ago
Absolutely. The majority of the programming world is obviously dumb. You are the true master.
ams6110 10y ago
A very non-PC joke from George Carlin springs to mind...

pmarreck 10y ago

> I find that the people who are the most obsessed about unit testing generally aren't good programmers to begin with. I don't think you can generalize this, neither subjectively (my shipping code quality has gone way up since I switched to TDD) nor empirically (evidence seems to indicate that you can achieve up to a 90% production bug reduction with a 15-35% upfront extra time cost doing TDD, which most would consider "worth it"). Secondly, this doesn't mean a very good programmer on a team doesn't have to write tests, if only to prevent others from breaking the behavior expectations of his code down the line. Thirdly, tests serve to validate that behavior if you yourself ever have to go back to the code to change or refactor it, so unless you are SO good of a programmer that you have perfect memory of the mental models of all your past code (which would put you in the extreme minority of all programmers), they will still come in handy.

jeremiep 10y ago
Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture prematurely. More often than not I see TDD yielding horrible, terrible software architectures and at that point you do need tests to maintain the resulting mess. TDD somehow assumes emergent architectures and I know from experience this is the worst way to architect something. NPM for example is full of well-tested libraries with poor architecture and bad usability (could be why everything is reinvented every 6 months) but I wouldn't call that a success story. I'm willing to bet the bug reduction from the extra time upfront doesn't come from doing TDD but actually thinking about the requirements and how they fit the larger picture. I really like the following story to illustrate this point: http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...
- pmarreck 10y ago
  That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)

entee 10y ago

I think unit tests are a great tool to motivate code that is simple and easy to reason about. After all, a good unit test is itself simple and easy to reason about. It also forces you to think about what is the simplest unit of software for a given task, helping design the software it is testing. Also, I've definitely had code I thought was well tested and good to go, but when I rigorously went back and wrote unit tests, I found subtle bugs I wouldn't otherwise have known to fix. That said, yeah it's not all it takes to get things right. Dogma is bad, but unit tests are an essential part of the toolkit for ensuring code quality.

kedean 10y ago
Yeah, i've found that my heavily unit tested code is often my best code, simply because designing it with that in mind yields the simplest, smallest units. If I know I'm gonna need to write a unit test later, I'm much more inclined to split a long function out into more sensible small ones, and I'm not going to try to combine two different behaviors (because that's hell to test).