golangのossを導入するかどうかgithubを見る時にベンチマークやカバレッジが載っていると指標にもなり，テストコードがどの程度担保しているかわかるので嬉しいです． ossの機能が要件を満たしているということが前提になりますが，メンテナンスもあまりされておらず速度も遅いようであれば自分で作成した方が遥かに良い（もしくはissueを立てたりpullRequest送ったり）gitにあげて欲しいなと思いました． ※ あくまで個人的な意見です．
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.12.6
BuildVersion: 16G29
$ go version
go version go1.9 darwin/amd64
自分は基本的にプロジェクトホームにテストが置いてある状態にしています．
ベンチマーク用のディレクトリを作成
$ mkdir bench
作成したディレクトリに現在のバージョンのベンチマークファイルを作成します．
$ go test -bench . -benchmem -count 5 -run none > bench/v(任意のバージョン)
上記のコマンドは -bench でベンチマーク， -benchmem でメモリ関連を表示， -count 5 でテストの回数を5回に設定， -run none でベンチマークだけ走らせているといったことをしています．
最後尾の > bench/v* は標準出力されたベンチマーク結果を v* ファイルにリダイレクトしています．
ベンチマークは信用のため最低でも５回は設定した方が良いと思います．
カバレッジとはテストコードが実際のコードに対してどの程度テストされているかの割合を%で表したものになります． つまり5行の関数が5つあり，テストコードが4つの関数でそれぞれの関数内のコードは全て通るようなテストコードが書かれていて，1つの関数ではテストコードが書かれていないとしたらカバレッジは80%になります． つまりテストコードがどの程度コードを通っているかの割合になります． ※ カバレッジが100%だからといって必ずしも機能の仕様を全て満たしているようなテストコードであるということではないので注意が必要です．
ベンチマークと同様にカバレッジディレクトリを作成します．
$ mkdir coverage
そして実際にカバレッジを作成します． カバレッジファイルを作成しますが，ベンチマークのようにカバレッジを出力しようとしても全体のカバレッジしか表示されません． そのため，関数ごとのカバレッジを表示したいため一度ファイルに出力してから関数ごとのカバレッジを出力します．
$ go test -coverprofile=cover.out # cover.outが生成される
$ go tool cover -func=cover.out > coverage/v(任意のバージョン) # go toolで解析
$ rm cover.out # 一時作成されたcover.outを削除
このようにすることで関数ごとのカバレッジが出力できます．
後はgithubにあげましょう． readmeにバッジとかつけてあげるとカラフルになって映えるかもしれません．
自分もまだまだOSSは数個しか作っていませんが，なるべく良いと思ったものは取り入れていこうと思います． こっちの方がわかりやすいし，見やすいよといったものがあれば教えていただけると嬉しいです．