Also, the shadowing of t in t.Run is intentional. You should not try to work around it. There's no risk of confusion either because you will always use the right one in the right place.
As that applies to software, a mock is a fully-fledged implementation of an interface, but not the implementation you use under normal use. For example, a mock might be an in-memory database where you normally use a persisted database. Not the real implementation, but does not try to deceive – it is equally functional.
Mockery appears to be an assertion library that, bizarrely, moves the assertions into interface implementation. What purpose does it serve? You are going to end up testing implementation details by using that, which is a horrible road to go down.
I wouldn't describe swapping a persisted DB for an in-memory DB mocking personally.
I'd add using testing.T.Cleanup for tearing down the testcontainer (or use a TestMain and a deferred if the container is slow and concurrency-safe.)
- I prefer state-based TDD as opposed to interaction-based (see https://martinfowler.com/articles/mocksArentStubs.html).
- I've used both testcontainers and dockertest, and from my experience dockertest is more robust.
- The capital T for the outer argument comes across as being hypercorrect. Why would one consider the shadowing of this argument bad?
It's perfectly ok to take what you like from them and leave the things you don't.
Is something that has 7 useful things and 3 things you disagree with merited to be buried from public view because of the 3 things you personally disagree with?
I've never really understood this perspective.
