[Comment removed by author]
DHH made valid point about this red-green-cycle TDD fundamentalism, but expanding it to whole unit testing is like throwing out the baby with the bath water.
Long live testing. Unit, functional, integration, you name it testing.
The author’s proposition are that TDD is “fun”, it’s a “journey” and it takes a long time to learn. I don’t think it stands up as a counter-argument to DHH’s post. It would be much more useful to talk about the value of TDD, and why it’s higher than its costs.
DHH also linked to this article which raises a lot of issues with unit testing: http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
The OP doesn’t address any of those either. So unfortunately, I found very little substance in this post.
I’ve seen the document document you link before and my first reaction was that it was a marketing white paper for a company that specialises in manual testing and outsourcing of testing. But when I read it, I found it confusing and unhelpful because it didn’t match my experience.
One of the purposes of unit testing is to create repeatable, automated tests to free up people to focus on the harder (and more interesting) problems. The paper even says it, which leads me to suspect that the author is using a different meaning of the phrase “unit test” than I am used to:
If you’re going to automate, automate something of
value. And you should automate the mundane stuff. You’ll
probably get better return on your investment by automating
integration tests, bug regression tests, and system tests than by
automating unit tests.
that the unit under test be designed for testability. This is how
hardware engineers do it: designers provide “test points” that
can read out values on a J-Tag pin of a chip, to access internal
signal values of the chip — tantamount to accessing values
between intermediate computations in a computational unit. I
advocate doing this at the system level where the testing focus
should lie; I have never seen anyone achieve this at the unit
level. Without such hooks you are limited to black-box unit
I’m not sure what to make of that. If anything makes use of white box testing, it’s unit testing.
Yes, that last part about black-box unit testing doesn’t seem clear. I think what he means is that the tests require you to change the design of your classes, functions or what have you in order to be able to poke their innards. So in practice, people end up with various tradeoffs where only parts of the system are unit-testable.
It’s been a while since I read that paper, but I think the rest of the points about unit tests were reasonable. In summary, it takes a lot of effort and potentially misdirects development work, but doesn’t provide much value (or sometimes even negative value). So it’s better to perform testing at a higher level. Anecdotally, this aligns with my experience and the experience of other developers I know.