Writing and maintaining tests can easily become a chore, which can lead you to avoid testing altogether.
One way to avoid this is to establish patterns that can be reused across tests, reducing the "how do I test this?" problem to a known quantity.
Not only does this make writing the tests faster, often a copy-paste-and-change, but your colleagues will be familiar with the patterns you've used. It means they can jump into your code and retain some level of familiarity, which translates to productivity, hugely useful in a team trying to move fast.
This posts shares one of the patterns we use in Go codebases to mock client libraries.
As an aside, while doing the final skim before publishing I wanted to reference a definition of a "seam" in programming.
I've always had this in my head as something Martin Fowler used, and thought it funny that when Googling "Martin Fowler seam", the top result was a very similar article about how to refactor code that accesses external services:
Writing and maintaining tests can easily become a chore, which can lead you to avoid testing altogether.
One way to avoid this is to establish patterns that can be reused across tests, reducing the "how do I test this?" problem to a known quantity.
Not only does this make writing the tests faster, often a copy-paste-and-change, but your colleagues will be familiar with the patterns you've used. It means they can jump into your code and retain some level of familiarity, which translates to productivity, hugely useful in a team trying to move fast.
This posts shares one of the patterns we use in Go codebases to mock client libraries.
Hope you find it interesting!