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....
One of the most feature-full ORMs for Go that I have worked with is Gorm. If you would like to learn more about it, I recommend checking out its official website and its documentation. Recenlty I wanted to write a small database seeding abstraction. Database seeding is a process in which an initial set of data is provided to a database when it is being set up or installed....
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 endeavor. The next logical step was to look for the 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 Ruby on Rails has heavily popularized test fixtures as a concept....
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: running selective tests. That’s because the traditional method 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 widespread testing libraries in Ruby, such as RSpec, force the programmer to approach testing from a BDD standpoint. Thus, coming to Go and learning about the table-driven test was 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....
If you remember anything from this article, remember this: go test is a command that automates the execution of test files and functions in a Go project. The go test command ships with Go itself, so if you have Golang installed, there’s nothing to check - it’s available on your machine. go test will recompile each package and any files with names matching the file pattern *_test.go. These *_test.go files can contain test functions, benchmark functions, and example functions....
Programming languages and tools often have conventions. These conventions help make our work more straightforward. Just like all tools out there, Go also has some conventions when it comes to testing. Some are defined in the language itself (official), while others are coined by community members (unofficial). In this article we will look at the naming conventions for files, functions and variables separately. File and package naming conventions Go’s testing package comes with an expectation that any test file must have a _test....
All developers appreciate code that works, yet we spend much of our working hours debugging existing code. When fixing existing code, what our test failures communicate is paramount to the debugging experience we have. That’s why in this article we will look at what it means to write a meaningful test failure message. We will look at its structure and how we can use some simple techniques to improve our test failure messages....
A short overview of the testing package The testing package from Golang’s standard library provides support for automated testing of Go packages. It is intended to be used in combination with the go test command. In combination with go test, this package expects certain naming conventions that we will cover in another article. Still, for this article, we have to know that: Every test file ends with *_test.go Every test function has the format TestXxx, where Xxx must not start with a lowercase letter The testing package exposes two different modes: testing and benchmarking....