I don’t think it’s fair to call this a “characteristic” with “a little overhead”.

Two reasons why it might not be realistic:

microservices (having +100 docker images to fetch/launch/.. each time you want to test things)

it’s damn slow. When I test I expect a really quick feedback. A mocked test is in ms, a container one is in seconds… This multiplied by hundred of tests, is a huge load on CI servers and something impossible on my laptop…

I think you’re raising a good point. Will update the post with this concern, or, if you prefer and don’t mind you comment on the Medium post yourself? In any case I’d like to thank you and credit you with it …

Mocking also allows me to test in isolation, which is the whole point of a unit test- I want to test a single, specific unit, that way if it doesn’t behave as expected, I know why (or at least, I’ve narrowed it down). Testing interactions with etcd with a real instance of etcd introduces all sorts of complexities that make it difficult to reason about the unit test.

Integration tests, sure, whatever, have at. The closer your integration tests get to a real-world environment, the better.

Hmmm. OK, here’s a question: does the fact that in my example the unit is all about directly reading from and writing to etcd change anything concerning your statement? I suppose I’m not sure I understand where you draw the line …