4 ms·

Unit Testing Sucks

2 points by sutro 18y ago

Allocator2008 18y ago
I have to respectfully disagree here, having done a bit of unit testing myself (JUnit, XMLUnit, CPPUnit). I think the better way to approach unit testing is have a resource on your team dedicated to unit tests, that way, one does not have to write unit tests for code oneself has written. I think I sense that is the big gripe, that writing unit tests on top of the deliverable takes time and is "boring". I worked at a place where I was on the development team, but my sole task, or primary task at any rate, was writing CPPUnit unit tests. I actually enjoyed it alot personally, found lots of bugs that never would have been found otherwise, and the QA department "felt better" knowing the deliverable had been unit tested before being delivered to QA. So, having done unit testing myself, sure I am "biased" but I think it makes for more stable deliverables to QA and therefore speeds up the whole QA cycle as a result. But probably ideally I would agree that having a different person write unit tests than the person who wrote the code being tested is good, in terms of not adding more work to an already over-worked developer.
- queensnake 18y ago
  My understanding (and even experience) is that, to get at everything you have to break your code up more than you might otherwise. Thus you have to be the developer to write unit tests.
  - stcredzero 18y ago
    He's missing the point you've just alluded to: in order to unit test everything that could break, it needs to be written in a way that you can get at everything. In general, the more easily testable code is the better designed code. So, if you're doing Test First development, you will write better designed code our of sheer laziness. In my experience, when developers decry writing unit test code as boring, they are: 1) Usually writing their test afterwards, so they've already gotten the reward 2) Have bad design habits (usually solitary programmer habits) and so find it a real drag to imagine tests for their code. Also, the article's understanding of the benefits of unit testing are pretty shallow. The way Unit Testing increases quality is much the same way code reviews and formal methods increase quality. It is the same reason we have double-entry accounting, or why people tell you to read your writing out loud to proofread it. If you make a point of checking yourself in a distinct, separate step, that cognitive separation makes you less prone to glossing over your errors. Unit testing is not a magical elixir and isn't perfect by any means. But the author doesn't really contribute to the discussion.

2 points by sutro 18y ago

Allocator2008 18y ago

I have to respectfully disagree here, having done a bit of unit testing myself (JUnit, XMLUnit, CPPUnit). I think the better way to approach unit testing is have a resource on your team dedicated to unit tests, that way, one does not have to write unit tests for code oneself has written. I think I sense that is the big gripe, that writing unit tests on top of the deliverable takes time and is "boring". I worked at a place where I was on the development team, but my sole task, or primary task at any rate, was writing CPPUnit unit tests. I actually enjoyed it alot personally, found lots of bugs that never would have been found otherwise, and the QA department "felt better" knowing the deliverable had been unit tested before being delivered to QA. So, having done unit testing myself, sure I am "biased" but I think it makes for more stable deliverables to QA and therefore speeds up the whole QA cycle as a result. But probably ideally I would agree that having a different person write unit tests than the person who wrote the code being tested is good, in terms of not adding more work to an already over-worked developer.

queensnake 18y ago
My understanding (and even experience) is that, to get at everything you have to break your code up more than you might otherwise. Thus you have to be the developer to write unit tests.
- stcredzero 18y ago
  He's missing the point you've just alluded to: in order to unit test everything that could break, it needs to be written in a way that you can get at everything. In general, the more easily testable code is the better designed code. So, if you're doing Test First development, you will write better designed code our of sheer laziness. In my experience, when developers decry writing unit test code as boring, they are: 1) Usually writing their test afterwards, so they've already gotten the reward 2) Have bad design habits (usually solitary programmer habits) and so find it a real drag to imagine tests for their code. Also, the article's understanding of the benefits of unit testing are pretty shallow. The way Unit Testing increases quality is much the same way code reviews and formal methods increase quality. It is the same reason we have double-entry accounting, or why people tell you to read your writing out loud to proofread it. If you make a point of checking yourself in a distinct, separate step, that cognitive separation makes you less prone to glossing over your errors. Unit testing is not a magical elixir and isn't perfect by any means. But the author doesn't really contribute to the discussion.