Testing with Go

You fire up your editor, grab your latest project, create your first *_test.go source file, and suddenly it feels like you don't have a clue what you are doing.

*You hear the sound of glass shattering*

What happened?!?!

Things were going so great. All those examples made sense, but now you don't even know where to start.

It seemed so easy to test that "Hello, world" HTTP handler, but how do you test complex handlers? You know, HTTP handlers that do something realistic like insert a record into a database, or use an API to verify someone's address.

For that matter, how do we verify that our database interactions are working as we expected? Or maybe your app has a global DB variable - does that mean testing simply isn't possible?

What about those APIs we are interacting with? Do we stub them? Do we hit the test API? What happens if we hit API rate limits or there isn't even a test API?

Alright, alright! Take a second to breathe and let me fill you in on a little secret...

Testing isn't hard, but simple tutorials don't do it justice

Testing isn't any harder than writing any other Go code. In fact, if we wanted we could test our code by just writing a main package and interacting with our application code. We could panic when something doesn't act the way we expected, and viola - we have a test!

But why does it feel so hard? Probably because we simplify the examples to the point that they lose all of their value.

Think about it, when is the last time you wrote a Palindrome function?

Never? So why are all these tutorials showing us how to test one?

Why aren't they showing us how to test realistic software? What happened to the example where we test a real HTTP handler that needs access to a data store? Or the tutorial where we build an API client and learn how to test it WITHOUT always hitting the real API. Wouldn't it be great if we could learn how to test a real web app with a real DB and a real integration to a payments API like Stripe?

Test with Go is different.

In this course you will learn how to test REAL software, not palindrome functions.

We will have to look at a few isolated examples in order to learn specific testing techniques, but that isn't enough to solidify a concept so we won't stop there. We will build real projects that teach you how to apply all of these testing skills in real software.

In one project we build a web application which allows us to address the complexities that come up while testing an application that uses a database, third party APIs, and more. In another project we look at how internal testing helps us verify our intermediate steps are correct, while also discussing the downside to testing unexported functions.

You will learn about common pitfalls to avoid in order to write more testable code. You will learn how to incrementally fix code that has already succumbed to many of these pitfalls, allowing you to avoid a massive PR that makes your reviewer cry inside.

When you run into an application with a global DB variable you won't need to give up on testing. You will learn exactly how to make small, manageable changes to the code that allow you to start testing it almost immediately.

The next time you are asked whether the data store should be mocked or if a real SQL database should be used you will be able to discuss the pros and cons of both approaches with your teammates and decide on a proper plan of action.

After completing this course you will have the knowledge and the skills necessary to start testing your own projects. You will still have to put in the work, but the mystery, the confusion, and the frustration will be gone.