For table-based testing, I have been using map[string]struct{...} for a while now instead of including the test name as a struct field. I have found it improves readability slightly and makes it harder to misname test cases (empty strings stand out more and duplicates won't compile).<p>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.
I'm far too lazy to write mocks by hand in go. You can generate a mock for a given interface with mockery <a href="https://github.com/vektra/mockery">https://github.com/vektra/mockery</a>
So unless I pepper every test and subtest with t.Parallel() it will always run sequentially ? I gotta try that. Also I wish I could just declare that once
Nice showdown of a bunch of scenarios.<p>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 would vote this down if I could for the following reasons:<p>- I prefer state-based TDD as opposed to interaction-based (see <a href="https://martinfowler.com/articles/mocksArentStubs.html" rel="nofollow">https://martinfowler.com/articles/mocksArentStubs.html</a>).<p>- I've used both testcontainers and dockertest, and from my experience dockertest is more robust.<p>- The capital T for the outer argument comes across as being hypercorrect. Why would one consider the shadowing of this argument bad?