March 2014: Testing, Delegation & C.

calendar Mar 24, 2014 · 3 min read · testing cgo  ·
Share on: linkedin copy

Please RSVP at Meetup and/or Google+.

Talks

Testing in Go: What You Need to Know

@MatthiasStone walked through Go's built-in testing package, using a contrived phone-number parser as the example. He showed table-driven tests — a slice of input/description structs looped over with t — and contrasted the standard library's plain reporting with third-party assertion frameworks such as testify/assert (assert.Error, assert.NoError, assert.Equal). The talk also covered Example functions, whose // Output: comments turn them into executable, checked documentation, and how String() output is verified through them. The takeaway is that Go's testing toolkit is small but sufficient, and assertions are optional sugar.

Key points:

  • Tests live beside code in _test.go files and run with go test.
  • Table-driven tests keep cases data-driven and easy to extend.
  • The standard library is enough on its own.
  • testify/assert adds readable Equal/Error/NoError helpers.
  • ExampleFoo() with an // Output: comment is a runnable, checked example.
  • String() output can be tested through those examples.
  • An external _test package keeps tests in the consumer's view.

@MatthiasStone (code)

Composition & Delegation

@nathany explained Go's preference for composition over inheritance. The starting point was manual delegation: an Employee holding a person field and forwarding calls explicitly (employee.person.Name()). Embedding (Person and Department inside Employee) removes the boilerplate by promoting Person's methods to Employee — but the relationship is one-way, and the embedded types know nothing about the employer, so there is no polymorphism. When two embedded types expose the same method, the selector becomes ambiguous at compile time; implementing Name() on Employee itself resolves it, and that method can call through to each embedded type.

Key points:

  • Go favors composition over inheritance.
  • Manual delegation works but adds forwarding boilerplate.
  • Embedding auto-promotes methods from the embedded type.
  • Embedding is one-way — no polymorphic "is-a" relationship.
  • Colliding promoted methods cause an ambiguous-selector compile error.
  • Defining the method on the outer type resolves the ambiguity.
  • The outer method can still delegate to the embedded implementations.

@nathany (code)

Go's Secret C Interface

@darkhelmetlive showed how to implement functions in C (and assembly) and call them from Go without cgo. Functions are declared in Go without a body (func Add(a, b int64) int64), then implemented either in an .s assembly file following the Go ABI with a TEXT ·Add(SB) symbol, or in a C file that includes the Go runtime header and writes its result through the argument pointer using FLUSH. The talk underlined the unusual calling convention — arguments and results are passed on the stack via frame-pointer offsets — and demonstrated subtracting in pure Go alongside the C and assembly versions. A GoConvey test suite verified all three.

Key points:

  • Declare the function in Go with no body, then supply the implementation.
  • .s files can implement it in assembly using the Go ABI.
  • C files can implement it by including runtime.h and writing the result to the argument slot.
  • TEXT ·Name(SB) marks the entry point; args and results are stack-based.
  • This avoids the cgo toolchain entirely.
  • Pure-Go implementations can sit alongside the C/assembly ones.
  • GoConvey table tests check add/sub/mul behave identically.

@darkhelmetlive (code)

News & Articles

Books

Events

  • dotGo - October 10 in Paris 119 €
  • Edmonton Go Meetup - April