Michael Whatcott
Michael Whatcott
Sr. Software Engineer

Mike was absolutely instrumental in the success of Smarty. He was one of our very first employees. He's had a personal hand in designing, building, or maintaining our US Street Address API, US Autocomplete API, US Extract API, as well as lots of code that works behind the scenes. He's also built a BDD testing tool for Go that got so popular that he could no longer maintain it on his own. Combine all of these incredible accomplishments along with his additional wealth of knowledge that he's put into our OSS libraries on GitHub and it's easy to see why we appreciate so much of what Mike has done for all of us at Smarty.

All posts by Michael Whatcott - Sr. Software Engineer

Go Naming ConventionsArrow Icon
By Michael Whatcott on October 18, 2018
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 know 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.
Let's build an xUnit-style test runner for Go!Arrow Icon
By Michael Whatcott on July 2, 2018
Writing test functions in Go is easy: go 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.
A History of Testing in Go at SmartyArrow Icon
By Michael Whatcott on March 28, 2018
I was recently asked two interesting questions: 1. Why did you move from GoConvey to gunit? 2. Are you recommending folks do the same? These are great questions, and since I'm a co-creator of GoConvey and principle author of gunit I feel responsible to give 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.
Scanning CSV in GoArrow Icon
By Michael Whatcott on January 5, 2018
For the purpose of this article, consider the following CSV data, slightly modified from the docs for encoding/csv: go 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: go reader := csv. NewReader(csvData) for { record, err := reader. Read() if err == io. EOF { break } if err != nil { // handle the error.
Testing in Go by Example: Part 6Arrow Icon
By Michael Whatcott on September 25, 2017
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.
Our Testing ToolsArrow Icon
By Michael Whatcott on November 3, 2016
Introduction TL;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 cost > A 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.
Testing in Go by example: Part 5Arrow Icon
By Michael Whatcott on September 15, 2015
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.
Testing in Go by example: Part 4Arrow Icon
By Michael Whatcott on August 11, 2015
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.
Testing in Go by example: Part 3Arrow Icon
By Michael Whatcott on May 11, 2015
Review: Welcome 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. Introduction In this post and the next few posts I'll focus on our approach to writing actual tests.
Ready to get started?