3 ms·

There is an interesting article which responds to this and mentions some misinterpretations of references: https://www.tedmyoung.com/looking-at-tdd-an-academic

• keithnz 8y ago
  I think that article is a necessary read after the original posted article. The original posted article seems a bit too keen to convince you of its point of view that it seems a bit disingenuous. My feeling about unit testing / integration test is you do as much of it as you can, trying to sincerely learn the lessons of how to do it it effectively, until you know why you don't need to do it. Or until you know what the right mix is. I started with Extreme Programming and testing around 18 years ago and my thinking has constantly evolved over that time. One of the biggest factors, I think, is project context and the nature of the software you are developing. I find in embedded systems, unit tests done extensively are very very useful. As is integration testing. In web systems, I find integration tests are often most useful as so much is all about gluing together various tech, and it's often the gluing the comes unstuck. However there is often chunks that have some interesting logic that lends itself to more extensive unit tests. Sometimes testing is just a mess because of the design. Too many things that are not really needed, too many layers, too many levels of abstractions, too much "future proofing". Then you see people start trying to throw unit testing around it, and it is mostly just useless and explodes out the amount of work to do. Often I think articles like the original are reactions to this scenario.