Demystifying Go (Golang), Google’s Programming Language: Unit Testing - Native Mocks - Part 2

Introduction

Welcome to another chapter in our journey through unit testing in Go. In this installment, we’ll explore two powerful native techniques for mocking external dependencies: Embedding Interfaces and Mocking HTTP Calls. These techniques will save you hours of frustration while keeping your tests clean, precise, and free of unnecessary gymnastics.

So, grab a cup of coffee, put on your gopher hat, and let’s dive into the code!

Embedding Interfaces

If you’ve ever had to deal with an interface crammed with dozens of unnecessary methods for your test, you know it’s like carrying a backpack full of bricks to a picnic: it just doesn’t make sense. That’s where Embedding Interfaces comes in, offering an elegant solution.

Imagine you need to test a function that depends on a massive interface, like AWS SDK’s DynamoDBAPI. This behemoth contains over 200 methods. That’s right, two hundred! Writing mocks for all of them would be the coding equivalent of digging holes at the beach during high tide.

Here’s the lifesaver: with Embedding Interfaces, you can create a type that “embeds” the desired interface and overrides only the methods you actually care about. Magic? Not quite — but close enough.

Check out a simplified example using the DynamoDBAPI interface and the GetItem function:

To implement this, simply declare a type that embeds the full interface but only customize the methods you need for your test. Here’s how it looks:

?? Heads up, Gopher! If any unimplemented method gets called on your mock, Go won’t forgive you: it’ll blow up with a panic due to a nil pointer. Here’s an example where we invoke svc.DescribeTable without mocking it — the result is catastrophic but educational:

Mocking HTTP Calls

Who hasn’t needed to mock an HTTP request at some point? When your application relies on other microservices via HTTP calls, unit testing can quickly become a challenge, especially if those services need to be running during your tests.

Thankfully, the httptest package comes to the rescue. It’s a real lifesaver for creating a mock HTTP server that stands in for the original implementation, allowing you to test HTTP-dependent functions in complete isolation.

Here’s the scenario: you have a function GetHttp that performs a GET request to a given URL. Using httptest, you can spin up a mock server and configure it to respond as you like. This ensures your tests are predictable, reliable, and independent of external factors.

Below is an example of how to configure httptest for your test:

This approach ensures that your tests are fast, predictable, and free from issues like flaky internet connections (or that notorious server that always “goes down on Fridays at 6 PM”).

Conclusion

Congratulations, gopher! You’ve just mastered two powerful tools in Go’s arsenal for writing unit tests with native mocks: Embedding Interfaces and Mocking HTTP Calls. While the first helps you tackle absurdly large interfaces, the second ensures your tests remain isolated from external dependencies.

With these techniques, your tests will not only function correctly but also shine with elegance — and might even earn you a few compliments from your teammates. After all, who can resist clean, testable code built on solid practices?

Keep exploring and applying what you’ve learned today. In the world of Go, the sky (or the performance of your tests) is the limit! ??