testing-in-go

No test suite is perfect. Some test suites are missing good helper functions; others are under-configured or over-customize. Some have obsolete packages included and are left unmaintained. Folks that have experience with more mature projects will likely agree that all of the above can be found in the wild. Often, when we test our Go programs, need to create files. Such files can be just fixture files, or whole file trees, to set up the correct environment for the tests to run....

WebSockets offer duplex communication from a non-trusted source to a server that we own across a TCP socket connection. This means that, instead of continually polling the web server for updates and having to perform the whole TCP dance with each request, we can maintain a single TCP socket connection and then send and listen to messages on said connection. In Go’s ecosystem there are few different implementations of the WebSocket protocol....

Go’s a great hammer for a lot of nails, one of the areas where I find it fitting is building HTTP servers. The net/http package of Go’s standard library makes it easy to attach HTTP handlers to any Go program. What I find delightful is that Go’s standard library, also has packages that make testing HTTP servers as easy as building them. Nowadays, it’s widely accepted that test coverage is important and useful....

Go v1.14 ships with improvements across different aspects of the language. Two of them are brand new t.Cleanup, and b.Cleanup methods, added to the testing package. The introduction of these methods will make it easier for our tests to clean up after themselves. This was always achievable through the careful composition of (sub)tests and helper functions, but since Go 1.14, the testing package will ship with one right way to do that....

Hardcoding the expected values in an assertion is a straightforward approach in testing. Most of the time, we know the expected output of the unit under test, so simply adding the raw value to the assertion works well. Things can get tricky when we are testing a unit whose output is cumbersome to hardcode. The straightforward remedy is to extract this cumbersome value to a file that we can then read and compare the output of the unit under test to the output of the file....

One of the biggest misconceptions is that doubles are a specific implementation of mocks or other testing constructs that we use in testing. Dummies, mocks, stubs, fakes, and spies ARE test doubles. Test double is the category of these test constructs. Over the years, there has been some confusion around this concept. It is my observation that this confusion arises from the naming of testing constructs that the popular testing frameworks use....

In software engineering, over the years folks have developed many patterns, techniques and refactoring maneuvers. Some have been long forgotten, while others have stood the test of times. Such a long-standing technique is dependency injection. It is a concept and a programming technique where a construct is passed (injected) to another construct that depends on it. In Golang, like in other languages, we use it to simplify our code and make it more testable....

When I was researching the topic of test fixtures, I couldn’t find much about their beginnings. My first search was about the name of the person who coined “test fixtures”. Unfortunately, that was not a fruitful edeavour. The next logical step was to look for etymology of the phrase “test fixtures”, but the only search result that made sense was a Wikipedia page on the topic. Judging by the Wiki page, it’s clear that test fixutures as a concept has been heavily popularized by Ruby on Rails....

Before we begin: The content in this article assumes knowledge of table-driven tests in Go. If you are unfamiliar with the concept, read this article to familiarize yourself. With table-driven tests as the most popular testing approach, there is one annoying problem that every programmer will face: selective running of tests. That’s because the traditional approach of testing using table-driven tests in a single test function is not decomposable in granular subfunctions....

Coming from Ruby, which has excellent testing tools and libraries, the notion of table-driven tests was unusual for me. The popular testing libraries in Ruby, like RSpec, force the programmer to approach testing from a BDD standpoint. Thus, coming to Go and learning about the table-driven test was definitely a new way of looking at tests for me. Looking back, Dave Cheney’s 2013 seminal blog post “Writing table driven-tests in Go” was very likely my gateway to table-driven tests....