In my experience, TDD and unit testing is awkward and uncomfortable when working with application code, since you often find yourself simply testing dependency wrappers, which has limited value. On the other side, integration tests are kludgy and uncomfortable when working with library code.
"Round peg, square hole" and all that. I often see two sides arguing for a universal testing strategy, when the use cases are very different.
I try to treat tests as nothing more than repeatable artifacts of whatever I was trying to do to verify the code I was writing was working. So if the code was primarily aimed at hitting a bunch of web services and making DB calls, then the tests will end up as integration tests naturally. If the code is doing a bunch of isolated calculations, then it will probably be unit tests.
This is a classic case of developers talking past one another and trying to force their use case on others in my opinion.
"nothing more than repeatable artifacts of whatever I was trying to do to verify the code I was writing was working" I really like this way of looking at things, and think I might adopt it myself. It's kind of a nice way of saying "test the interface", but more like "test the interface of the code exercised by the primary consumer of the interface".
I try to treat tests as nothing more than repeatable artifacts of whatever I was trying to do to verify the code I was writing was working. So if the code was primarily aimed at hitting a bunch of web services and making DB calls, then the tests will end up as integration tests naturally. If the code is doing a bunch of isolated calculations, then it will probably be unit tests.
This is a classic case of developers talking past one another and trying to force their use case on others in my opinion.