続き書きました。続: Go入門したときに開発環境を考えた話

Goを初めて1時間の人間のメモです。ベストプラクティスやご指摘等あればよろしくお願いします。

Goを書き始めるにあたって以下のことがしたかったです。

さっくり関数を書いて、単体テストを通すことでGoの勉強がしたい
GOPATHに依存したくない
本コードとテストをキッチリ分けたい

まず、GOPATH自体には特に問題なく受け入れることができました。Goには、便利なCUIツールが多く存在するので、そう言った目的では、昔からGo(go get)を利用してきました。しかし開発時に、$GOPATH/src下にプログラムを書いていくのは、受け入れることができませんでした。常に本格的な開発をするならば、とてもいい機構だと思いますが、現状のような初心者ではグローバル空間を汚染しながらプログラムを書くのは気が引けます。もっと気軽に書いて消してを繰り返したいと考えました。

テストコードを書くに辺り公式マニュアルを漁っていたところHow to Write Go Codeという素晴らしいリンクを発見しました。そこには、局所的にGOPATHとコマンドサーチパスを変更・追加する手法が載っていました。しかし、気軽に作って消してを繰り返したい自分としては毎回、環境変数の「状態」を意識するのはツライなあと思いました。

$ export GOPATH=$HOME/work
$ export PATH=$PATH:$GOPATH/bin

さらに、ビルドやtestの度にパッケージを指定するのは面倒です。

$ go build github.com/user/stringutil

そして見つけたツールが、gbでした。とっても良いツールです。トップページにはシンプルに以下のような一文が書いてあります。

A project based build tool for the Go programming language.

これで、GOPATHから解放されて、テストを楽に書く生活ができそうですね？

gbはプロジェクトベースのツールなので、ディレクトリ構造を強制されます。と言ってもすごい単純です。srcを掘ってファイルを配置するだけです。

以下のように、依存ライブラリを管理することも出来るようです。

$ gb vendor fetch [依存ライブラリ]
$ gb vendor restore

配置が終えたら、テストを実行するだけです。特にテストの位置やbuildなどを気にすることなく、サクッと実行出来てしまいました。

$ gb test -v
stringutil
=== RUN   TestReverse
--- PASS: TestReverse (0.00s)
PASS

最後になりますが、一つ不満が残りました。本コードとテストコードを分けて書くことが出来ませんでした。以下が理想の書き方です。しかし、現状では大きなものは書かずに、細々としたものを書かないので問題ないかもしれません。ある程度大きなものを書こうとしたときは、どうするんでしょう？と疑問は残っています・・・。

$ tree .
.
└── src
    ├── main
    │   └── stringutil
    │       └── reverse.go
    └── test
        └── stringutil
            └── reverse_test.go