Go for C# developers: Unit testing

Let’s talk about unit testing and Go. The fact that unit tests typically are placed side by side with the code (in the same package as the code under test) and how Go deals with exposing functions outside of a package leads to some interesting things.

Over the years I’ve always encountered a certain resistance against unit testing certain things for example things that depends on time. This is because you need to expose certain things as dependencies and they are typically only added as dependencies for test purposes as production code would always use for example system time. While it is easy to argue for why abstracting time is the correct thing from a puristic perspective, exposing it “for test purposes only” is sometimes frowned upon. And while one might argue that the abstraction is a good thing, Go actually kind of eliminates the need for these “test purpose only” discussions. For better or worse...

So while this might feel good, the only real good thing is that I can have fewer religious discussions on what is proper abstractions to expose on an object. The worse part is that Go essentially mimics the behavior (in C#) of you making all your tests friend classes in the production code to give them access to internals, a pattern I’ve always hated as it makes the production internals tightly coupled to the tests. The fact that this doesn’t have to be added explicitly in Go is IMHO actually a drawback as you can create a tight coupling between tests & production code accidentally.

So overall there is no excuse for not properly testing your code in Go as the language make it easier than in some other languages but be warned as some of the good patterns forced upon you in other languages are not forced upon you in Go. Which I actually find surprising given how many other things Go force upon you out of the box.