4 ms·

Let me just state a fact: every programmer tests code. Whether you're checking a command line output, experimenting in the REPL or reloading a browser, you're t

by rlander 15y ago

Let me just state a fact: every programmer tests code. Whether you're checking a command line output, experimenting in the REPL or reloading a browser, you're testing your code. What rubs me the wrong way is that, instead of a simple "you know all that ad hoc testing that you do? There's a way to automate that that'll probably save you some time and let you test the same things, in an automated fashion, with the press of a key...", non-testers usually get a condescending "oooh my sweet summer child, what to you know of code?"

mjbellantoni 15y ago
This is a great point and one I often try to make (with differing levels of success.) I believe Brooks says you're going to spend 50% of your development time testing (25% unit, 25% system) I think. You're going to spend that amount of time in one chunk or you're going to amortize it (and probably make the total time spent testing longer.)
evincarofautumn 15y ago
This is exactly the problem that I see with the testing/TDD culture. Automated tests are wonderful because they save me time, not because they are the singular Holy Magic Grail Bullet of software development. My software tends to be obsessively modular as it is, because I’m lazy. I can hold a complex tangled system in my head. It just sucks. So even when I only test manually, I am reasonably assured that nothing’s broken. But there’s no need to do manually what your computer can do automatically.
leftnode 15y ago
And I think that is warranted. It's unprofessional and sloppy to not write automated tests, and developers who are unprofessional should be called out on it. The problem is, in my experience, I've tried your first line and it just doesn't register (for whatever reason). So, I use the second now.
rickmb 15y ago
I'm afraid the statement that "every programmer tests code" is not a fact. Not by a long shot. In fact the vast majority of bugs are the result of not testing changes at all, in any way shape or form. Committing code changes without even running it (or only running it to the most simple and predictable of scenarios) is not an exception. Many programmers, especially those that don't like writing test, simply assume it works "because it was simple". It's this utterly unrealistic and unprofessional hubris that gets condescending reactions. Given the damage it does to both the product at hand and our profession in general, I would say condescension is a rather mild response to this behaviour.
- tonyarkles 15y ago
  At one of my past jobs, the threshold for "should I commit this?" was "does it compile?". The rationale was that if there were problems with it, they'd be caught during "acceptance testing" (which was probably 6 months down the road). I didn't stick around for very long...
  - prodigal_erik 15y ago
    I've seen PHP committed and deployed to production with syntax errors, which means nobody ever tried the offending pages even once. I also left that shop pretty quickly, because I don't think options keep vesting if I garrote somebody with a network cable.
- rlander 15y ago
  > In fact the vast majority of bugs are the result of not testing changes at all I never said every programmer tests 100% of their code all of the time. Even when you're just checking the output of a "hello world", you're effectively testing your code. It might be the only test ever made, but it is a test. > In fact the vast majority of bugs are the result of not testing changes at all Now you're making a bold claim that, AFAIK, isn't backed up by research. Just to be clear, I like tests, and I like automated tests even more. I just don't think they necessarily merit 50% of my own time because they're not some panacea that will magically auto correct badly designed software. Test are written to find bugs, not to eliminate them altogether; you can't guarantee your code is bug free because of tests.

by rlander 15y ago

mjbellantoni 15y ago

This is a great point and one I often try to make (with differing levels of success.) I believe Brooks says you're going to spend 50% of your development time testing (25% unit, 25% system) I think. You're going to spend that amount of time in one chunk or you're going to amortize it (and probably make the total time spent testing longer.)

evincarofautumn 15y ago

This is exactly the problem that I see with the testing/TDD culture. Automated tests are wonderful because they save me time, not because they are the singular Holy Magic Grail Bullet of software development. My software tends to be obsessively modular as it is, because I’m lazy. I can hold a complex tangled system in my head. It just sucks. So even when I only test manually, I am reasonably assured that nothing’s broken. But there’s no need to do manually what your computer can do automatically.

leftnode 15y ago

And I think that is warranted. It's unprofessional and sloppy to not write automated tests, and developers who are unprofessional should be called out on it. The problem is, in my experience, I've tried your first line and it just doesn't register (for whatever reason). So, I use the second now.

rickmb 15y ago

I'm afraid the statement that "every programmer tests code" is not a fact. Not by a long shot. In fact the vast majority of bugs are the result of not testing changes at all, in any way shape or form. Committing code changes without even running it (or only running it to the most simple and predictable of scenarios) is not an exception. Many programmers, especially those that don't like writing test, simply assume it works "because it was simple". It's this utterly unrealistic and unprofessional hubris that gets condescending reactions. Given the damage it does to both the product at hand and our profession in general, I would say condescension is a rather mild response to this behaviour.

tonyarkles 15y ago
At one of my past jobs, the threshold for "should I commit this?" was "does it compile?". The rationale was that if there were problems with it, they'd be caught during "acceptance testing" (which was probably 6 months down the road). I didn't stick around for very long...
- prodigal_erik 15y ago
  I've seen PHP committed and deployed to production with syntax errors, which means nobody ever tried the offending pages even once. I also left that shop pretty quickly, because I don't think options keep vesting if I garrote somebody with a network cable.
rlander 15y ago
> In fact the vast majority of bugs are the result of not testing changes at all I never said every programmer tests 100% of their code all of the time. Even when you're just checking the output of a "hello world", you're effectively testing your code. It might be the only test ever made, but it is a test. > In fact the vast majority of bugs are the result of not testing changes at all Now you're making a bold claim that, AFAIK, isn't backed up by research. Just to be clear, I like tests, and I like automated tests even more. I just don't think they necessarily merit 50% of my own time because they're not some panacea that will magically auto correct badly designed software. Test are written to find bugs, not to eliminate them altogether; you can't guarantee your code is bug free because of tests.