by Brian Gesiak

Swift compiler and swift-corelibs-xctest committer. Creator of Quick, the Swift (and Objective-C) testing framework. Former Japanese literature translator.

Page 3

RESTful Go: An API Server with 90%+ Test Coverage in 260 Lines of Code

I wanted to try building a small, RESTful API for a mobile app. And, like any respectable piece of software, I wanted close to 100% test coverage.

 The Premise: Signature Collection for Petitions

I built an API to collect signatures for online petitions. Each signature is composed of a name, age, and short message. The server responds to the following requests:

HTTP Verb Path Use
GET /signatures List all signatures
POST /signatures Create a signature

 The Dependencies

  • Martini: A Go web framework, like Sinatra. Used for routing.
  • mgo: Pronounced “mango”. A Go driver for MongoDB, used to persist the signatures.
  • Ginkgo & Gomega: Essential for Go unit testing.
  • gory: Used to easily create signatures for unit testing.

If you’re following along at home, you’ll need to go get these libraries:

go get github.com/go-martini/martini
go get github.com/martini-contrib/binding
go get

Continue reading →

Continuous Integration in Go: Ginkgo & Coveralls

I’ve recently started programming in Go. But you can’t really call it programming without:

  • a comprehensive set of tests
  • a CI server to make sure they’re all passing

I took some time to see what was available in Go. I came up with the following:

  • Unit tests: Ginkgo & Gomega
  • Continuous Integration: drone.io (or Travis CI)
  • Code coverage: Upload metrics to coveralls.io using Gover and Goveralls

 Unit Tests with Ginkgo

If you’ve used RSpec (Ruby), you’ll love Ginkgo and its matcher library Gomega:

var _ = Describe("Set", func() {
    var set *Set
    BeforeEach(func() { set = NewSet() })

    Describe("adding and removing elements", func() {
        It("adds elements", func() {


Continue reading →

Intel® Xeon® Phi Coprocessor High Performance Programming

Continue reading →

iOS UI Component API Design



 Source Code


Continue reading →

Code Reading: Message Stubbing in RSpec

RSpec isn’t just nested context blocks and expect(...).to expectations; it also includes a powerful mocking library: rspec-mocks.

Take the following spec, which stubs Car#honk:

# car_spec.rb

class Car
  def honk
    puts 'Honk!!'

describe Car do
  let(:car) { described_class.new }

  it 'receives honk' do
    # Stubs the `#honk` message and returns `nil`.
    # The actual implementation, which prints "Honk!!",
    # is never executed.
    allow(car).to receive(:honk)

How does RSpec achieve this? Let’s examine the source code step-by-step.

 The allow syntax

allow is defined in RSpec::Mocks::Syntax. As with the should and expect(...).to syntax in rspec-expectations, RSpec::Mocks::Configuration allows a user to enable or disable their preferred message stubbing syntax:

RSpec.configure do |config|
  config.mock_with :rspec do |c|
    # Both `#stub`

Continue reading →

Apple Templates “Considered Harmful”

Note to readers: During the actual talk I played up the fact I was using the phrase “considered harmful” facetiously. You had to be there.


Apple Templates Considered Harmful from Brian Gesiak


アップルのテンプレートは有害と考えられる from Brian Gesiak

You can see the sample code here.

Continue reading →

RSpec 3.0: Under the Covers

RSpec 3.0: Under the Covers from Brian Gesiak

 More on RSpec

  • Code Reading: RSpec 3.0 Expectations
  • Code Reading: Rspec 3.0 Shared Examples
  • Code Reading: RSpec 3.0 Output Formatting
  • Code Reading: RSpec 3.0 Message Stubbing
  • Hands-On: Shared Examples in RSpec

Continue reading →

Behavior-Driven Development with Kiwi


iOS Behavior-Driven Development from Brian Gesiak


iOSビヘイビア駆動開発 from Brian Gesiak

 Source Code

The source code for the sample app is on GitHub. Enjoy!

 More on Kiwi

  • Code Reading: Shared Examples in Kiwi

Continue reading →

Thoughts on Atom

I’ve been using GitHub’s new editor, Atom, to work on sending a few patches to Git. Overall, it hasn’t been a terribly pleasant experience.

 Slow and Unresponsive

The Git repository has some very, very large directories, so I can understand why Atom hangs for a few seconds every time I try to expand one of them in the file navigator. That is, I would understand, if Sublime Text 2 wasn’t able to do so instantaneously.

Furthermore, using the fuzzy file finder (⌘+T) to open large C files (1000+ LoC) caused Atom to stall for a bit, then display the file without syntax highlighting, then stall for a bit more, then colorize the tokens. Sublime opens even large files effortlessly.

 Frequent Crashes

Run make on the Git source code and you’ll generate a bunch of binary files. Accidentally click on one in Atom’s file navigator and BOOM!–the app crashes or otherwise becomes unresponsive. I wish

Continue reading →

Code Reading: Expectations in RSpec 3.0

If you’ve downloaded the RSpec 3.0 beta, you may have noticed that the should method now triggers a deprecation warning:

Using should from rspec-expectations’ old :should syntax without explicitly enabling the syntax is deprecated. Use the new :expect syntax or explicitly enable :should instead.

The expect syntax has been included since RSpec 2.11, released in July 2012:

# rather than:
foo.should == bar

# ...use:
expect(foo).to eq(bar)

RSpec core member @myronmarston explained in 2012 that the new syntax allows RSpec to avoid monkey-patching the Ruby Object class. Monkey-patching Object was the source of a number of cryptic errors. In fact, one of the main goals for RSpec 3.0 has been a “zero monkey-patching mode”–a version of RSpec which does not add methods like describe and should to every object.

This post examines how RSpec avoids monkey-patching by looking at should and expe

Continue reading →