gobrain @gobrain - Tumblr Blog

In itself, this is a very useful idiom. In concrete terms, create a struct type which contains data for a given test case. This ought to include input and expected + actual output. Your test is then a loop over a slice of your test cases, checking expected vs. actual. As the link says, you can see examples of this in tests for the fmt package (link).

One challenge is a nice, clean way to write the actual test, the "assert." Assuming your test method is relatively simple, this ought to do nicely:

if got, want := Foo(input), expected; got != want { t.Errorf("Foo(): got %v, want %v", got, want) }

It is a little boilerplate-y. On the other hand, it's just a few lines and it's very clear what's going on.

You can find examples of this pattern in clone_test.go in the html/template package.

More generally, you can find more interesting test-related patterns from the src/pkg directory of your Go repo: grep 'got != want' `find -name '*.go'`.

#testing

Idiom: iterating over file

Sometimes you'll want to read lines from a buffer, say, and you'll want to do it with a for loop.

The idiom looks something like this:

for line, err := buf.ReadString("\n"); err == nil; line, err = buf.ReadString("\n") { // stuff }

If line and err have already been initialized in this context, it's legal to drop the initializer:

for ; err == nil; line, err = buf.ReadString("\n") { // stuff }

Note the presence of the space after the for but before the semicolon. That's required.

#for

If you want to encode a string such that it's safe for URLs, or decode a string which has been encoded as such, here's how you do it in Go.

s := "I asked him: would you like to go sailing?" e := url.QueryEscape(s) fmt.Println(e) e, _ = url.QueryUnescape(e) fmt.Println(e)

This prints:

I+asked+him%3A+would+you+like+to+go+sailing%3F I asked him: would you like to go sailing?

#net #url

This is a blog post with a nice overview of some of the stuff you can do with functions.

In particular, I'd forgotten about how you can streamline the use of higher-order functions using named types. The example at the link is something like type IntMapper func(int) int), which you might then pass to a function func Map([]int, FooFunc) []int.

If you like Go, it's probably worth following this blog.

#func #tutorials

weekly vs. tip

I discovered this somewhat by accident. You can access docs for Go weekly and tip-of-tree via some additional URLs: weekly.golang.org and tip.golang.org.

Release is presumably just golang.org.

#docs

From the site description:

This is an unofficial, community-authored reference wiki for the Go Language.

The goal is to write small, focused reference/summary articles on individual topics of the language.

Here's a page talking about common mistakes: CommonMistakes.

#tutorials #docs

This is similar to the Go widget on the homepage which lets you write and run some code. The main feature here is the "Share" button, allowing you to share via a URL the code you've written.

It seems handy for some kinds of quick prototypes or demos.

#tools

It almost seems redundant to link to this. However, I skipped it and did myself and it a disservice.

I got the most value out of the programming exercises. At first they walk you through syntax, and occasionally have you fix stuff. That's as far as I got the first time, which meant that I missed the exercises.

At the end of a section they'll have you actually write code. One example has you using an image library to generate images, for instance. I thought it was fun and rewarding.

They have a note about how you can install it locally if you prefer.

#tutorials

NewFoo, foo.init() idiom

There's an idiom I've observed which goes something like this:

func NewFoo(param bar) (Foo, error) { f := new(Foo) err := f.init(param); err != nil { return nil, err } return f, nil }

This is nice if Foo.init has to do some non-trivial work which may end in failure, like parsing a string.

There are multiple examples in the standard Go packages. Here's one from mail.

#idioms

You can run your own searchable, local documentation server via godoc:

godoc -http=:6060 -index=true

Depending on the quality of your connection, this can be faster than hitting the "real" site.

As a bonus, the docs for installed packages (your own or otherwise) should show up.

#docs #tools #godoc

From the README:

Gocode is a helper tool which is intended to be integraded with your source code editor, like vim and emacs. It provides several advanced capabilities, which currently includes:

Context-sensitive autocompletion

It is called daemon, because it uses client/server architecture for caching purposes. In particular, it makes autocompletions very fast. Typical autocompletion time with warm cache is 30ms, which is barely noticeable.

I believe you need to be on the latest weekly (cd $GOROOT && hg pull && hg update weekly) for this to work.

#gocode #tools

Fake Reader/Writer in tests

If you're testing something like net.Conn, you may want to test that any logic which ultimately writes to it is writing the right thing. As far as I know, anything with the Writer interface will suffice for dependency injection (DI). So what can you use, short of rolling your own every time?

Enter bytes.Buffer.

fakeConn := new(bytes.Buffer) expected := "foo" writeSomeStuff(fakeConn, expected) // does the writing actual := fakeConn.String() // retrieve what was written

In general, it seems like Go makes this part of DI relatively easy. You could go a step further declare type FakeConn bytes.Buffer and add arbitrary methods to it. Your FakeConn can then satisfy whatever interface you like and/or provide convenient helper methods for tests.

What I haven't worked out yet is the idiomatic way to support DI. Hopefully the core Go package tests will have some insight.

#bytes #net #testing

Trending Blogs

Recently Viewed Blogs

gobrain