I see your point, but I don't agree with it, at least not entirely.
As you say, TDD is both about testing and designing. To be honest, for me it is about UNIT testing. Not integration one. It is good, when you can clearly distinct these two kinds of testing in your source code.
For example, you are writing about database communication. There is a well known repository pattern which handles that. Giving another layer for db communication provides you an opportunity to test only your code when testing classes which use repository and in other scope you can test whole db communication.
As you wrote, there is also a possibility to extract and test only these methods, which you really need.
I think that a truth lies somewhere in the middle. We should distinguish, if it is possible, our dependencies from 3rd parties, in unit test, test only our code. Also it is good to create integration test exactly for 3rd party libraries, communication etc.
I enjoy reading your article as I am big fan of any kind of testing especially TDD approach. Thanks for sharing.
Thanks for the comment.
You have a very good point. I've introduced a test that is tightly coupled to CarrierWave here, which made it kind of integration tests (which I didn't originally intend to do).
So here I've described that mocking would be even worse idea.
But I agree that the better solution would be to have a wrapper.
This article describes not so recent events, but I'll research the possibility of wrapping CarrierWave and ActiveRecord for my future projects.
I agree with Paweł.
From my experience, avoiding mocks on some tests turns them into integration tests and that's not always the goal when doing TDD.
I do like the idea of having wrappers, but that doesn't reduce the need for mocking completely when dealing with 3rd party libs.
We’re a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.