I’m reading TDD By Example by Kent Beck right now and one of the Red Bar Patterns really resonated with me. It’s called the Learning Test. Here’s the scenario. You have a new library or framework that you’re implementing. Instead of just diving into TDD’ing the implementation, you can write some learning tests. These are tests where you validate how you expect the 3rd party tool to work for you. I see this as testing the contract between your application and the 3rd party tool.

Today I learned a little bit more about how pointers work in Go. We had this object that we want other functions to directly modify. So we pass a pointer to this object to various functions and then in our tests we check to see that the original object has been modified correctly. We also have these helper functions that are supposed to return a pointer to an object buried inside of the struct.

I’m developing my own budgeting app using Go and have been using it to learn new things as well. For testing, because I’m TDD’ing the entire project, I decided to just use the built-in Go testing framework. I use Ginkgo at work and enjoy it, but decided to see what vanilla testing in Go is like. After writing a bunch of tests for a lot of my boilerplate functions, I quickly had a lot of duplicated set-up code that looked like this at the start of all my tests: