5 ms·
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 devel
by 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 agoHe'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.