1. 3

Beginning this year we switched our main language from Python to Go. It took a bit of practice to get the testing flow to something we’re happy with. Right now it works like a charm though. Federico did a nice little writeup on some of the tools/workflows we use.

  1.  

  2. 4

    Seems all very fine, but I would caution against GoMock.

    GoMock has been abandoned internally at Google for good reasons. It’s ugly to read, it’s hard to write, and it masks underylying architectural problems. “…refactoring our code to have simple, interface-based components would add too much noise” addresses the architectural thing head on, and I just don’t see a world where having a bunch of GoMock code is better than having some tightly defined and documented interfaces in the system under test instead.

    But I liked everything else :)

    1. 1

      Post author here :) Thank you for your feedback - and I agree with your point about architecture: a good Go design almost always mean that you don’t have to use stuff like GoMock. I know it’s heavy, it’s ugly, and it’s not doing anything special, but, I think, there are certain scenarios where it can have sense to just spawn a compiled mock to speed up the development, without sacrificing too much in terms of design. Sill, from scratch I’d always say: “don’t use GoMock (or similar)” when you can achieve the same result with plain and clear code, but when evaluating the tradeoffs I think it can still be a viable option given certain circumstances.