{"id":5882,"date":"2015-07-27T16:15:48","date_gmt":"2015-07-27T13:15:48","guid":{"rendered":"http:\/\/www.webcodegeeks.com\/?p=5882"},"modified":"2015-12-16T11:30:58","modified_gmt":"2015-12-16T09:30:58","slug":"testing-in-go","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/web-development\/testing-in-go\/","title":{"rendered":"Testing in Go"},"content":{"rendered":"

This post is based on a presentation I gave for the Boston Go group in May. You can watch the video here<\/a><\/p>\n

For me, Go is like coming back to formal programming after the crazy world of Ruby for a little while. It reminds me of C with all the sharp corners sanded off; Go is such a simple language.<\/p>\n

Some of my favorite things in the programming world are tests, web applications, and databases. Half of all my talks are about tests, in fact. So let\u2019s talk about testing in Go.
\n <\/p>\n

Testing Basics<\/h2>\n

The most basic example of testing in Go just needs whatever package you\u2019re working in \u2014 you don\u2019t change it \u2014 you import \u201ctesting,\u201d and then any function that you start with Test is going to get run by Go\u2019s testing harness. It\u2019ll take one parameter (a testing T), and you can use that to call the different testing functions in Go.<\/p>\n

package basics\r\n\r\nimport (\r\n    \"encoding\/hex\"\r\n    \"testing\"\r\n)\r\n\r\nfunc TestTruth(t *testing.T) {\r\n    if true != true {\r\n        t.Error(\"everything I know is wrong\")\r\n    }\r\n}<\/pre>\n
So here, I\u2019m just making sure that true<\/strong> is equal to true<\/strong>. Instead of doing something in the affirmative and saying \u201ctrue<\/strong> is equal to true<\/strong>, or we should crash,\u201d I\u2019m saying \u201cIf true<\/strong> isn\u2019t true<\/strong> then there\u2019s an error.\u201d Generally, you talk about things in the worst case with Go, which I think flows with the way you write Go: calling methods and checking errors and doing something if something goes wrong.<\/p>\n
\"type-T\"<\/a><\/p>\n
Let\u2019s talk about some of the testing functions on T<\/a>. You can call errors, you can fail the tests, you can see if it failed. Fatal<\/strong> will make an error message, but it will also stop the test right where it is. You can also just log debugging stuff, so when you turn your verbosity up, you can see all your messages. You can leave them in there for yourself if you ever have to debug a test.<\/p>\n
func TestBroken(t *testing.T) {\r\n    if true != false {\r\n        t.Error(\"expected\", true, \"got\", false)\r\n    }\r\n\r\n    if 1+1 != 4 {\r\n        t.Fatal(\"Can't proceed!\", 1+1, 4)\r\n    }\r\n}<\/pre>\n
But 99 percent of the time, the only ones you\u2019ll care about are Error<\/strong> and Fatal<\/strong>. Fatal<\/strong> is just an error plus a fail. So Error<\/strong> is like you\u2019re making a big list of everything that\u2019s going wrong on this test; you can have a whole ton of errors, and this will list them all. But with Fatal<\/strong>, it will stop. You can\u2019t even do your other checks, so you have to pretty much bail out of the test at this point.<\/p>\n\n\n\n
\u201cGenerally, you talk about things in the worst case with #Golang\u201d \u2013 @ngauthier<\/a>Click To Tweet<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Often, I\u2019ll just use Fatal<\/strong> because the tests depend on the pieces you\u2019ve created as you go along. But sometimes, if you have a big object with a ton of fields, it\u2019s nice to be able to do a lot of error statements and see exactly which ones worked and which ones didn\u2019t while you\u2019re trying to work on some database persistence, for example.<\/p>\n
$ go test -v .\/basics\/\r\n=== RUN TestBroken\r\n--- FAIL: TestBroken (0.00s)\r\n    package_test.go:13: expected true got false\r\n    package_test.go:17: Can\u2019t proceed! 2 4\r\nFAIL\r\nexit status 1\r\nFAIL github\/com\/ngauthier\/testing-go-presentation\/basics    0.006s<\/pre>\n
So when you run this, the error will say expected true got false<\/strong>, and then it will continue on to the fatal that says Can\u2019t proceed! 2 4<\/strong><\/p>\n
The neat thing here is that you can put as many arguments as you want into Error<\/strong> and Fatal<\/strong>, and it\u2019ll stringify them nicely. It\u2019s a really nice interface.<\/p>\n
func TestError(t *testing.T) {\r\n    dest := make([]byte, 0)\r\n    if _, err := hex.Decode(dest, []byte{8}); err != nil {\r\n        t.Error(err)\r\n    }\r\n}<\/pre>\n
$ go test -v -run Error .\/basics\/\r\n=== RUN TestError\r\n--- FAIL: TestError (0.00s)\r\n    package_test.go:27: encoding\/hex: odd length hex string\r\nFAIL\r\nexit status 1\r\nFAIL github\/com\/ngauthier\/testing-go-presentation\/basics    0.004s<\/pre>\n
A really common pattern in Go (and therefore in tests) is errors. In this case, I\u2019m going to decode some hex, and I put in some invalid bytes that aren\u2019t going to decode into hex. So when we run this, we get an error. You\u2019ll do the same thing as you do with a normal error check in Go, but then you just give that error directly to Error<\/strong>. It\u2019ll print your error out with a nice little line number where the error came out.<\/p>\n
$ go test -v -run Error .\/basics\/\r\n\r\n    -run regexp\r\n        Run only those tests and examples matching the regular expression.\r\n\r\n    -v\r\n        Verbose output: log all tests as they are run. Also print all text from Log and Logf calls even if the test succeeds.<\/pre>\n
You can give it a run with a regex, which can just be a string if you want to just run an individual test. That can help when you\u2019re refactoring, and you make a little change, and it breaks everything, and you have to go hunt down individual pieces and just want to focus on a piece of the puzzle.<\/p>\n
Testing HTTP<\/h2>\n
To level up our example, let\u2019s talk about what a lot of people do with Go, which is HTTP servers.<\/p>\n
type App struct {\r\n    Message string\r\n}\r\n\r\nfunc (a *App) ServeHTTP(w http.ResponseWriter, r *http.Request) {\r\n    w.Write([]byte(a.Message))\r\n}<\/pre>\n
Here\u2019s an app that stores a message. I\u2019m going to implement ServeHTTP<\/strong> on my app. That means that this app is going to function as an http.handler<\/strong>, so Go\u2019s HTTP server will be able to accept the app. All the app does is write the message out, no matter the parameters you give it. Pretty dumb server.<\/p>\n
func TestHello(t *testing.T) {\r\n    app := &App{Message: \"hello\"}\r\n    s := httptest.NewServer(app) \/\/ http provides its own test objects\r\n    defer s.Close()\r\n\r\n    resp, err := http.Get(s.URL) \/\/ test from the outside\r\n    if err != nil {\r\n        t.Error(err)\r\n    }\r\n    if body, err := ioutil.ReadAll(resp.Body); err != nil {\r\n        t.Error(err)\r\n    } else if string(body) != \"hello\" {\r\n        t.Error(\"expected\", \"hello\", \"got\", body)\r\n    }\r\n}<\/pre>\n
I\u2019m going to test this by creating the app, then I\u2019m going to use the HTTP test package\u2019s NewServer<\/strong>, which is a lot like http.server<\/strong>. However, they\u2019ve done a couple of nice things for you \u2014 you don\u2019t have to specify the port that you want to run it on, for example. If there\u2019s a collision, they\u2019ll re-randomize the port for you. So you get your own little server that\u2019s going to work well in a test scenario.<\/p>\n
Then I\u2019m going to get on that server\u2019s URL; we\u2019re really testing from the outside. If you were to boot up a server, serving my app, and somebody hit it as an HTTP client and actually connected to that socket and made that request, what are you going to get? This is very different than if I had said app.servehttp<\/strong> and then given it a response writer and a request object.<\/p>\n
Now I\u2019m going to convert the body to a string and compare that to hello<\/strong>, which is what I initialized the message with. If that wasn\u2019t hello<\/strong>, I\u2019m going to do my error with expected<\/strong> and got<\/strong>. You\u2019ll notice that I still made expected<\/strong>, hello<\/strong>, and got<\/strong> as three separate strings with commas. It\u2019s nice to keep that format.<\/p>\n
func fakeApp(msg string) *httptest.Server {\r\n    app := &App{Message: msg}\r\n    return httptest.NewServer(app)\r\n}\r\n\r\nfunc get(t *testing.T, s *httptest.Server, path string) string {\r\n    resp, err := http.Get(s.URL + path)\r\n    if err != nil {\r\n        t.Error(err)\r\n    }\r\n    body, err := ioutil.ReadAll(resp.Body)\r\n    if err != nil {\r\n        t.Error(err)\r\n    }\r\n    return string(body)\r\n}<\/pre>\n
Let\u2019s talk about factories and helpers. Tests are code too; they\u2019re not just scripts that run alongside your code. It helps to treat your tests like real code, and you\u2019ll see this in the standard library tests too.<\/p>\n
In this case, I wrote two helpers to make this easier on me. This is my fake app, which is going to run an HTTP test server. I\u2019ll initialize the app with whatever message I passed to the server, and I\u2019ll return an HTTP test version of the server.<\/p>\n
The second one I wrote is get<\/strong>. You give it your testing instance and a server and a path, and it makes a get request to that server and path, checks for error. It reads the body and checks for an error and returns the string version of that body. So this is going to do the whole get for me and send it back for any path on my server.<\/p>\n
func TestHelpedHello(t *testing.T) {\r\n    s := fakeApp(\"hello\")\r\n    defer s.Close()\r\n    if body := get(t, s, \"\/\"); body != \"hello\" {\r\n        t.Error(\"expected\", \"hello\", \"got\", body)\r\n    }\r\n}<\/pre>\n
Once I have these two, my test gets a lot easier to read. In this case, my get<\/strong> is doing some error checks for me. I don\u2019t just have a lot of little helpers that don\u2019t do anything. I\u2019ve made get<\/strong> do some assertions to make sure that when I got something back from get<\/strong>, it was going to work.<\/p>\n
Testing Interactions<\/h2>\n
So that was all about testing individual components. Let\u2019s walk through an example of testing interactions between components \u2014 that\u2019s usually where all the interesting testing stuff comes from. When you have two big, complicated pieces working together, that\u2019s when everything becomes difficult.<\/p>\n
In this case, I\u2019m using a simple example of a train and an engine.<\/p>\n
type Engine struct {\r\n    speed int\r\n}\r\n\r\nfunc NewEngine() *Engine {\r\n    return &Engine{}\r\n}\r\n\r\nfunc (e *Engine) Speed() int {\r\n    return e.speed\r\n}\r\n\r\nfunc (e *Engine) Accel() {\r\n    e.speed += 10\r\n}\r\n\r\nfunc (e *Engine) Decel() {\r\n    e.speed -= 10\r\n}<\/pre>\n
The engine is going to store private speed. It\u2019ll have a constructor that\u2019s going to return a pointer to an engine struct; Accel<\/strong> is going to increment speed by 10; Decel<\/strong> is going to decrement speed by 10.<\/p>\n
func TestEngine(t *testing.T) {\r\n    e := NewEngine()\r\n    expectSpeed(t, e, 0)\r\n    e.Accel()\r\n    expectSpeed(t, e, 10)\r\n    e.Decel()\r\n    expectSpeed(t, e, 0)\r\n}<\/pre>\n
To test the engine, we make a new engine. I expect speed to be 0. I\u2019ll accelerate it, expect my speed to be 10; I\u2019ll decelerate it and expect to be back at 0.<\/p>\n
func expectSpeed(t *testing.T, e *Engine, s int) {\r\n    actual := e.Speed()\r\n    if actual != s {\r\n        t.Fatal(\"expected\", s, \"got\", actual)\r\n    }\r\n}<\/pre>\n
expectSpeed<\/strong> will compare the actual to the speed you gave it and give a fatal if the speed was not equal to what was expected. This is another example of having a helper, so you don\u2019t have to repeat these four lines every single time.<\/p>\n
Note: As your software gets more complicated, you\u2019re probably going to want some helpers to set things up. But it should also alert you \u2014 if you have a lot of helpers, it means your code is hard to use because it requires a lot of set up. So at that point, it may be time to break things into packages.<\/p>\n
type Train struct {\r\n    engine *Engine\r\n}\r\n\r\nfunc NewTrain() *Train {\r\n    return &Train{\r\n        engine: NewEngine(),\r\n    }\r\n}\r\n\r\nfunc (t *Train) Go() {\r\n    t.engine.Accel()\r\n    t.engine.Accel()\r\n}\r\n\r\nfunc (t *Train) Stop() {\r\n    t.engine.Decel()\r\n    t.engine.Decel()\r\n}\r\n\r\nfunc (t *Train) Speed() int {\r\n    return t.engine.Speed()\r\n}<\/pre>\n
Now I\u2019ve got a private engine on the train. My constructor that returns a train is going to call the engine constructor to give us a new engine. Go<\/strong> just accelerates twice, Stop<\/strong> is going to decelerate twice, and Speed<\/strong> will return the speed.<\/p>\n
The thing that I really care about is how Train<\/strong> and Engine<\/strong> are going to work together and how they\u2019re constructed.<\/p>\n
func expectTrainSpeed(t *testing.T, tr *Train, s int) {\r\n    actual := tr.Speed()\r\n    if actual != s {\r\n        t.Fatal(\"expected\", s, \"got\", actual)\r\n    }\r\n}\r\n\r\nfunc TestTrain(t *testing.T) {\r\n    tr := NewTrain()\r\n    tr.Go()\r\n    expectTrainSpeed(t, tr, 20)\r\n    tr.Stop()\r\n    expectTrainSpeed(t, tr, 0)\r\n}<\/pre>\n
The train test is going to be pretty simple \u2014 looks pretty similar to what we had before.<\/p>\n
\u201cIntegration\u201d test<\/h3>\n
The train actually has to have a real engine, and it actually does stuff to the engine. That\u2019s the only way our test is going to pass \u2014 they are integrated together. We\u2019re testing acceleration by inspecting speed.<\/p>\n
However, we\u2019re not looking at how the train and the engine are interacting with each other. If we really unit tested the train, we\u2019d give it a fake engine that it was going to play around with. We\u2019d tell the train to go, and then we\u2019d see what the train tried to do to the engine. Notice that such a test would only test Go<\/strong>. It\u2019s not testing Go<\/strong> and Stop<\/strong> and Speed<\/strong> like the integration test was.<\/p>\n
Obviously this example is really contrived. If your code\u2019s that simple, there\u2019s no reason to go to those lengths. But what if Engine<\/strong> was some remote resource that you had to call over a JSON API through your own Train<\/strong>, and it was hard to set up and requires a bunch of authentication keys and has to be running on a port and all that junk? Then you\u2019d really want to start faking out your engine. After all, we don\u2019t really care about the engine, we just want to make sure the train does the right thing with the engine.<\/p>\n
type Speeder interface {\r\n    Speed() int\r\n}\r\n\r\ntype Engine interface {\r\n    Speeder\r\n    Accel()\r\n    Decel()\r\n}\r\n\r\ntype engine struct {\r\n    speed int\r\n}\r\n\r\nfunc NewEngine() Engine {\r\n    return \u014bine{}\r\n}\r\n\r\nfunc (e *engine) Speed() int {\r\n    return e.speed\r\n}\r\n\r\nfunc (e *engine) Accel() {\r\n    e.speed += 10\r\n}\r\n\r\nfunc (e *engine) Decel() {\r\n    e.speed -= 10\r\n}<\/pre>\n
To be able to work with a fake engine, we have to refactor our engine behind an interface. To do that, I tossed in the Speeder<\/strong> interface. The big change is that instead of being a struct, Engine<\/strong> is now an interface type. It\u2019s a speeder, and it will provide acceleration and deceleration.<\/p>\n
Our actual engine is going to become a private struct engine. People outside of the engine package will not be able to access our engine struct. They\u2019re only going to be able to see the interface. Our constructor is going to make an instance of the private struct engine and then return it as an engine interface. So we\u2019re making an engine<\/strong> and returning it as an Engine<\/strong>, and Go is going to cast it over for us. It\u2019ll allow it if our engine<\/strong> implements the Engine<\/strong> interface.<\/p>\n
To implement that interface, we have to implement Speed<\/strong>, and we have to implement Accel<\/strong> and Decel<\/strong>.<\/p>\n
So we never expose any struct attributes in our public interface. We\u2019re pretty safe, and this refactor will be pretty easy. So now we can pass the engine around.<\/p>\n
func expectSpeed(t *testing.T, speeder Speeder, speed int) {\r\n    actual := speeder.Speed()\r\n    if actual != speed {\r\n        t.Fatal(\"expected\", speed, \"got\", actual)\r\n    }\r\n}\r\n\r\nfunc TestEngine(t *testing.T) {\r\n    e := NewEngine()\r\n    expectSpeed(t, e, 0)\r\n    e.Accel()\r\n    expectSpeed(t, e, 10)\r\n    e.Decel()\r\n    expectSpeed(t, e, 0)\r\n}<\/pre>\n
Now, we have a totally public-facing interface for Engine<\/strong>. This test is pretty much the same as when Engine<\/strong> was a struct. It\u2019s just now with an interface, which means all we can do is access methods on it.<\/p>\n
type FakeEngine struct {\r\n    AccelCalls int\r\n    DecelCalls int\r\n}\r\n\r\nfunc NewFakeEngine() *FakeEngine {\r\n    return &FakeEngine{}\r\n}\r\n\r\nfunc (e *FakeEngine) Accel() {\r\n    e.AccelCalls += 1\r\n}\r\n\r\nfunc (e *FakeEngine) Decel() {\r\n    e.DecelCalls += 1\r\n}\r\n\r\nfunc (e *FakeEngine) Speed() int {\r\n    return 0\r\n}<\/pre>\n
Now let\u2019s make a fake engine. We want to implement the engine interface with it. This is pretty much the dumbest fake I could make \u2014 there are way more interesting ways to do these, but the goal here isn\u2019t so much to implement an engine as it is to keep track of what the interactions were like. The real goal here is to test Train<\/strong>\u2019s behavior and test it without needing a real engine.<\/p>\n
type Train struct {\r\n    engine Engine\r\n}\r\n\r\nfunc NewTrain() *Train {\r\n    return &Train{\r\n        engine: NewEngine(),\r\n    }\r\n}<\/pre>\n
We have to do a little refactoring on Train<\/strong>. The only thing that changes is Engine<\/strong>. Since it\u2019s an interface, you don\u2019t want to pass pointers to interfaces around. It gets very confusing very fast. So you always just pass the interface around. You won\u2019t actually know if it\u2019s a pointer or not, which is a really fun thing about Go.<\/p>\n
So our engine is now just an instance of the Engine<\/strong> interface. We also call the constructor as we normally would, so no big changes there.<\/p>\n
func trainWithFakeEngine() (*Train, *FakeEngine) {\r\n    t := NewTrain()\r\n    e := NewFakeEngine()\r\n    t.engine = e\r\n    return t, e\r\n}\r\n\r\nfunc TestTrainGo(t *testing.T) {\r\n    tr, e := trainWithFakeEngine()\r\n    tr.Go()\r\n    if e.AccelCalls != 2 {\r\n        t.Error(\"expected\", 2, \"got\", e.AccelCalls)\r\n    }\r\n}<\/pre>\n
Notice that my test\u2019s name has changed. It used to be TestTrain<\/strong>, and now we\u2019re testing TrainGo<\/strong>. We\u2019re going to call my constructor that gives us a train and a fake engine, we\u2019re going to call TrainGo<\/strong>, and then we\u2019re expecting that the engine had Accel<\/strong> called twice. It\u2019s like if you took a train, set it up in a warehouse, plugged something else into the port that controls the engine, and just made sure it said \u201cacceleration\u201d twice. As opposed to, you know, putting an actual train on an actual track and seeing if it runs into anything.<\/p>\n
Next, I\u2019m going to do what\u2019s called setter injection. I take the engine, and I inject that dependency into Train<\/strong>. I can do this because I\u2019m in the same package. Because this test is in the same package along with Train, I can access private methods. I can screw around with objects in ways that our users aren\u2019t allowed to do.<\/p>\n
func trainWithFakeEngine() (*Train, *FakeEngine) {\r\n    t := NewTrain()\r\n    e := NewFakeEngine()\r\n    t.engine = e\r\n    return t, e\r\n}\r\n\r\nfunc TestTrainStop(t *testing.T) {\r\n    tr, e := trainWithFakeEngine()\r\n    tr.Stop()\r\n    if e.DecelCalls != 2 {\r\n        t.Error(\"expected\", 2, \"got\", e.DecelCalls)\r\n    }\r\n}<\/pre>\n
Interface public stuff<\/h3>\n
It\u2019s usually a good idea to use an interface for anything you\u2019re going to be exposing publicly. The only time you wouldn\u2019t want to do that is when you have, for example, data objects that are often going to be value objects. Such as anything that represents a request payload. People are just going to interact with its fields, not really call methods on it.<\/p>\n
But usually interfaces are the way to go, for a few reasons:<\/p>\n