Forem: Zach Peters

Testing in Go with table drive tests and Testify

Zach Peters — Mon, 26 Oct 2020 13:43:39 +0000

(Originally posted at https://thehelpfulhacker.net/posts/2020-10-13-golang-testify-table-tests/)

Testing in Go

Over the past years of using Go on and off I have slowly settled on a few things for testing. I am by no means a rigorous TDD developer, but I have been trying to make testing more and more a part of my normal code.

I try to pick bits and pieces of different testing best practices, but the one thing I know about myself as a developer is that if it feels overly complicated at the moment there is a good chance I will skip it. The other thing I have learned is that I tend to start out with proof-of-concept "throw away" code for my prototypes and then spend a lot of time and gain some frustration trying to build that into a more stable/production type system.

Below are my notes on how I build up a "low impact" testing scenario from the beginning that is flexibile further down the road. The key to testing is trust and if you can trust your tests early on it gives you to confidence to iterate with less fear of breaking something

Nothing below will be arcane or earth-shattering, just some personal notes to save some time googling and maybe the seeds of an idea for another developer

"Normal" tests

Before we jump into table testing I wanted to write a very quick refresher on testing - in general - in Go. In Go, we like to follow a few conventions. When I started this did feel a bit messy and scattered to me. I was used to languages like Elixir where it is more conventional to keep all of your tests in a test folder. The side-effect of this, at least in my mind, was to always think of tests as something opitonal that lives "to the side" of your code. This encourages lazy habits for me. Out of sight, out of mind...

In Go things are different, at least if you follow the common conventions. In Go your tests will normally live in a file in the same folder as your code named with an _test.go. For example, mylib.go would have a corresponding test file called mylib_test.go. Again, to me this seemed cluttered in the beginning. As I got used to it, it really did help me switch mentally to the thought that my tests and code are one "thing". Also, if i see that i do not have any _test files I know right away that some work needs to be done.

Now that we have the file naming out of the way I will show you the most basic example of code and the corresponding tests. I will leave some links that explain testing in Go much better then I will.

mylib.go

package mylib

import "fmt"    

func MyFunction(in string) (out string, err error) {
    out = fmt.Sprintf("Hello: %s", in)
    return out, nil
}

mylib_test.go

package mylib

import "testing"

func TestMyFunction(t *testing.T) {
    out, err := MyFunction("Bob")
    if err != nil {
        t.Errorf("Should not get an error")
    }
    if out != "Hello: Bob" {
            t.Errorf("Should have gotten expected output")
    }

}

Really this is great. It's simple and to the point. You can get a ton of mileage out of just this format. Get some output, maybe check for errors and check that the error is what you expect. It is Go so you can make this testing or comparison as elaborate or simple as you like.

Additional reading on testing in Go

Table driven tests

Over time, using the techinique above, you will start to develope some routines and common patterns. In Go, there are many things that lead to "boilerplat" code. The best example is the if err != nil convention of handling errors. You are free to continue to write this, or you may wish to reduce your code and create a generic handling function.

Much like this you can imagine testing the same function over and over again with differnt inputs could become tiresome. This brings us to table driven tests!

The main idea is that we can write the general code once and only vary the parts that change. Through a few common Go idioms we can create a powerful testing "framework" that is easy to elaborate on. More importantly, it is easy to read and reason about.

Let's imagine the same scenario above. In "table testing" format it would look something like this.

mylib_test.go

package mylib

import "testing"

func TestMyFunction(t *testing.T) {
    // myTests is a slice of structs
    // The struct holds our inputs and expected outputs
    // There is nothing special about the naming of the fields
    // it is just my own convention
    var myTests = []struct {
        inputName string
        expectedOutput string
        expectedError error
    }{
        // Now we define the test scenario/struct this form we are 
        // using is just a shorthand of defining the struct and initialising its
        // values at the same time. 
        // This is really just an elaborate form of:
        // var myString string = "My String"
        {inputName: "Bob",  expectedOutput: "Hello: Bob", expectedError: nil},
    }


    // Now that we have created our "test case" we need to actually test it
    // _ is the index give by range, we don't need this
    // tt is just a placeholder, it can be called anything.  I just 'tt' by convention
    // because it is easy to type!
    for _, tt := range myTests {
        // First lets get our output.  I like "actual" or sometimes "got" to distinguish it from
        // the "expected" output we'll compare it to
        // tt.inputName is the inputName field of whatever loop of
        // the testing struct we are on.  In this case "Bob"
        actualOutput, actualError := MyFunction(tt.inputName)
        // Now, much like we did before lets test our outputs and make sure
        // they match our expectations

        // Make sure the actual error matches our expectation, which is *nil*
        if actualError != tt.expectedError {
            t.Errorf("Should not get an error")
        }
        // Make sure our output matches
        if actualOutput != tt.expectedOutput {
            t.Errorf("Should have gotten expected output")
        }
}

The astute reader will notice that we didn't actually save any lines. In fact, it looks like we added some. That is true for this very simple case. The true power of this technique comes when you want to add another test.

So let's say we want to test names using Korean characters. In our initial way of testing we'd have to copy and paste most of the function and create another, nearly duplicate, function.

In our new testing format, we just add a single line. What we are adding is another value to our tesitng struct. So right below the line for "Bob" we can add the followng:

{inputName: "Jian", expectedOutput: "Hello: Jian", expectedError: nil},

It's that simple. We added our testing "case" and since we are looping below it will loop through each struct and test them all the same.

Want to add another. Easy. Just add another line:

 {inputName: "지안",  expectedOutput: "Hello: 지안", expectedError: nil},

In the beginning this might all seem like overkill. We have seen though, even with a few basic tests we gain some advantages. To summarise you get a lot out of a little extra up front work of setting up your tests in "table" format.

Positives

Consistency in testing
Easy to add new tests
Easy to add / reason about the tests

Negatives

Requires a little extra work up front
You might need to get creative when checking output and errors since the same test runs every time

Some links on table testing:

Testify

Testify is an amazing, time-saving package that I use about three functions from. Testify is very well-designed and has high regard in the community, for good reason. My testing purposes are generally very limited so I just don't get the opportunity to use and explore all of the power that is there.

There is excellent documentation on their website so I'm not going to recreate it here. I will just give you a small example of how I would use it in our example above.

Do yourself a favor and spend some time reading through this package and see all of the great ways it can improve your testing.

One general recommendation that might not be obvious. 99% of the time you want to use require instead of assert. Require will stop testing on a failure, assert will continue along.

mylib_test.go

package mylib

import (
    "testing"
    "github.com/stretchr/testify/require"
)

func TestMyFunction(t *testing.T) {
    var myTests = []struct {
        inputName string
        expectedOutput string
        expectedError error
    }{
        {inputName: "Bob",  expectedOutput: "Hello: Bob", expectedError: nil},
        {inputName: "Jian", expectedOutput: "Hello: Jian", expectedError: nil},
        {inputName: "지안",   expectedOutput: "Hello: 지안", expectedError: nil},
    }

    for _, tt := range myTests {
        actualOutput, actualError := MyFunction(tt.inputName)
        //if actualError != tt.expectedError {
        //  t.Errorf("Should not get an error")
        //}
        require.Equal(t, tt.expectedError, actualError, "optional message here")
        //if actualOutput != tt.expectedOutput {
        //  t.Errorf("Should have gotten expected output")
        //}
        require.Equal(t, tt.expectedOutput, actualOutput)
}

Honestly, 90% of the time this is all I use. In a future post we'll explore more of the massive list of assertions you get with Testify.

Extras

Here are some great extras on testing that I didn't have a better place for:

Play around with code and share with others - https://play.golang.org/
Some best practices for testing - https://medium.com/@matryer/5-simple-tips-and-tricks-for-writing-unit-tests-in-golang-619653f90742
Test Suites in Testify - https://brunoscheufler.com/blog/2020-04-12-building-go-test-suites-using-testify
A really fun discussion about Testify on the Go Time podcast - https://changelog.com/gotime/139

Thanks for reading

If you enjoyed this or have any questions let me know. You can contact me here https://www.thehelpfulhacker.net/about/

My method of organizing email

Zach Peters — Fri, 28 Feb 2020 00:46:03 +0000

Today I wanted to share a quick email organization tip that I've refined over the years. Ideally, I try to pull every piece of relevant information out of email as often as possible and stick it into Evernote or an org-mode notes file. Getting information out of email and into an information system of some sort gets you 90% of the way, but there will always be that bit of info you missed in the flood of new emails. To deal with this I follow the process below to increase my ability to find the information I need.

The first order of business is to get information out of email. Email is a great tool for communication but it was never intended to be an information repository. Search will almost always be cumbersome and even if you find the email you were looking for it can take a great deal of cognitive effort to reconstruct what the train of thought was or way that email was important. Email generally doesn't allow for meta-data so by capturing and "editorializing" the information in your own note-taking system you can add in the relevant context
Practice Inbox Zero. There are really only three "states" that email should live in. By practicing the art of quickly classifying emails in these categories you can quickly "deal with" large volumes of email rather than letting it build up:
1. "New" - email that you haven't seen yet
2. "Actions" - something you need to do
3. "Archive" - something you need to hang on to
Here is my modified version of "Inbox Zero" with the different folders I have found fit my work-style feel free to improve on this.
1. 0-Action - Emails that are requests or reminders of things i need to do. If there is a specific task/deadline I will generally remove this to my "official" todo list in a different application and archive the email. Generally what is in here are reminders or items I need to do sometime.
2. 1-Hold - Informational emails that i need close at hand but do not represent a "todo" item. This should be a temporary holding place for "favorites". An example was a code that I needed for access to a system. I knew I'd only need it for a short amount of time so I moved the email there and then moved it to 2-Archive after a week.
3. 2-Archive - This is where you put everything that isn't in another folder. Storage is cheap. Save Everything. Rely on good search abilities in your mail client to retrieve anything that you haven't deemed important enough to add to your notes. If you spend more than three minutes searching for something add it to your note-taking system for the future.
4. 3-Feedback - This is where I keep positive (and negative) feedback to refer back to periodically.
5. 4-Awesome - Funny emails, pick-me-ups, etc. It's good to make time during the day to stop being so serious and enjoying work
6. 5-Templates - If i write the same email or answer the same question more than once I create a blank email and use it as a template

What organization systems do you use to keep the flood of email/information manageable? Please let me know!

Optimize Your Notetaking With Glyphs

Zach Peters — Fri, 28 Feb 2020 00:44:36 +0000

I wanted to share a quick tip that I've been using for years to make my notes (written and typed) more useful.

By nature I am a pretty disorganized note-taker. When jotting down notes I typically work in a very scattered "mind map" layout. I find if I try to keep to any sort of outline I tend to need to squeeze more and more notes into a confined space. What has evolved from this is basically a messy page of notes with all shorts of connecting lines, doodles, etc.

While this fits my brain well it is often difficult to pick out the bits that I need to "take action" on. Usually my understanding of what I have taken notes on is solid, but things like action items, additional research I need to do and other "meta" information gets lost in the structure - I guess you could call it "not seeing the trees for the forest"

Over time I have developed a short list of standard "glyphs" that I use in my written notes to help these items stand out:

(!) - Action item - Something I need to do
(N) - Note item - Something I need to document
(?) - Research item - Something that needs further research
(@) - Contact - Someones contact information

Do you have any note-taking tips? I'd love to hear them.

Stupid Telnet Tricks

Zach Peters — Fri, 28 Feb 2020 00:42:55 +0000

As a system administrator, it is often necessary to do a "sanity check" from time to time. Most problems become simple when you can break them down into their various parts. Often, though, we take the services we use for granted. We know that the web server is running, email "just works"...right??? Using some of the tricks below, you can verify that these services, in fact work, as you assumed and save yourself a lot of time and trouble.

HTTP

telnet server 80
GET / HTTP/1.1

SMTP

telnet server 25
Trying X.X.X.X...
Connected to localhost.
Escape character is '^]'.
220 sever ESMTP Exim 4.69 Wed, 07 Jan 2009 21:53:57 -0600
HELO foobar.com
250 server Hello localhost [127.0.0.1]
mail from: <a href="mailto:test@foobar.com">test@foobar.com</a>
250 OK
rcpt to: <a href="mailto:you@somewhere.com">you@somewhere.com</a>
250 Accepted
data
354 Enter message, ending with "." on a line by itself
payload
.
250 OK id=1LKlz9-0000cW-Tz
quit
221 server closing connection
Connection closed by foreign host.

POP3

telnet mail.foobar.com 110
Trying X.X.X.X...
Connected to mail.foobar.com.
Escape character is '^]'.
+OK The Microsoft Exchange POP3 service is ready.
USER username
+OK
PASS password
+OK User successfully logged on.
STAT
+OK 6 48274
LIST
+OK 6 48274
1 11274
2 11269
3 4929
4 4461
5 13350
6 2991
.
QUIT
+OK Microsoft Exchange Server 2007 POP3 server signing off.
Connection closed by foreign host.

What are your favorite telnet tricks?

I am sure most of these are old-hat to many of you, what other "stupid telnet tricks" do you have?