All posts by Michael Whatcott - Senior Software Engineer

ReviewWelcome to part 3 of our "Testing in Go" series. If you're new here, feel free to catch up before reading on. In part 1 of this series I eluded to our perceptions of the standard testing tools provided by the Go tool and the standard library and what was missing for us. We all have different expectations of a testing tool and so it's no wonder that so many have been created. Part 2 of the series focused on how we have made the act of running tests effortless and automatic. IntroductionIn this post and the next few posts I'll focus on our approach to writing actual tests.

It's been said that naming is one of the two hardest problems in computer science, along with cache invalidation and 'off-by-one' errors. (See what I did there?) Do you ever find yourself wondering what policies and practices you could adopt to make your life easier when reading code you wrote months ago? Or maybe you're up at night wishing you knew how to write code in such a way as to maximize adoption and convenience for your users? Well, look no further because we've anticipated the need, solved the problem, and now we're sharing our knowledge and wisdom at no charge, all out of the goodness of our hearts in this comprehensive, totally no-nonsense (nudge, nudge, wink, wink) style guide of Go naming conventions.

Writing test functions in Go is easy:package stuff import "testing" func TestStuff(t *testing. T) { t. Log("Hello, World!") } Running test functions is also easy:$ go test -v === RUN TestStuff --- PASS: TestStuff (0. 00s) stuff_test. go:6: Hello, World! PASS ok github. com/smartystreets/stuff 0. 006s Preparing shared state for multiple test functions is problematic. The usual recommendation is to use table-drive tests. But this approach has its limits. For us, xUnit is the ideal solution.

I was recently asked two interesting questions:Why did you move from GoConvey to gunit?Are you recommending folks do the same?These are great questions, and since I'm a co-creator of GoConvey and the principal author of Gunit, I feel responsible for giving a thorough answer. For the impatient, here's the TL;DR:Question 1: Why did you move to gunit?After using GoConvey and feeling consistent friction with that approach, we came up with an alternate approach that was more aligned with what we value in a testing library and which eliminated said friction.

For the purpose of this article, consider the following CSV data, slightly modified from the docs for encoding/csv:csvData := strings. NewReader(strings. Join([]string{ first_name,last_name,username, "Rob","Pike",rob, Ken,Thompson,ken, "Robert","Griesemer","gri", }, "\n")) Here's how you read the data, line by line, using the Reader provided in that package:reader := csv. NewReader(csvData) for { record, err := reader. Read() if err == io. EOF { break } if err != nil { // handle the error.

For this installment of the Testing in Go series we'll be talking about a grouping of packages that facilitate general-purpose comparisons in various contexts. Since the most common context is testing it seemed like this series was the right place for the discussion. We generally refer to these comparison functions as assertions (cue ominous background music and spooky sound effects). You may have already read the opinions found on the Golang FAQ related to assertions. "Why does Go not have assertions?"Go doesn't provide assertions.

IntroductionTL;DR: Choose an approach to software testing that helps your organization create the best possible end results. That might mean using and/or creating a few tools and/or libraries along the way. Or, maybe not. What follows is a description of what we do at SmartyStreets, couched as a response to Dan Mullineux's equally valid way of doing things. The costA favourite test helper library, with some simple test assertion functions clearly has some value. . . They [testing libraries] are not so bad, but they come at a cost, defer to avoid them.

For this installment of the Testing in Go series I'll share a really nifty way to deal with time in your unit tests. When the behavior you are testing depends on the current time it can be tricky to assert on the results because the current time is a moving target. So, usually we end up resorting to approximations in our assertions that, while functional, always bother me a bit. In some cases, depending directly on the system's current time prevents acceptable test coverage. Consider this trivial example, which defines a calendar service with a method that identifies the current quarter of the current calendar year:File: calendar.

I think it's time for a slight detour. In part 1 we covered the basics of testing in go. In part 2 we covered a few slick ways to execute tests. In part 3 we covered some of our recent endeavors at Smarty to build on the basics. Toward the end of that post, we went into some detail regarding our approach to assertions. The assertions referenced in the GoConvey project are actually their own separate project that are imported into GoConvey. The nice thing about separating the assertions into their own separate project is that they can be used, well, separately.