Day 22: cl-coveralls
これは fukamachi products advent calendar 2016 の22日目の記事です。
今日はcl-coverallsについて話します。
CI
Common LispはTravis CIのオフィシャルサポートはありませんが、cl-travisやRoswellを使って複数処理系をテストすることができます。
Common LispライブラリのCIは僕にとってはなかなかライフチェンジングで、今まで手元でSBCLでテストしてpushしていたのがClozure CLでは落ちるとかがすぐわかったり。CL-DBIのようにテスト用にRDBMSをたくさん用意しなければいけないようなものもPull Requestでテストできるのでパッチをもらっても安心してマージできます。
僕のライブラリはもちろんのこと、他の新しいライブラリでもTravis CIは当たり前に使われるようになりました。
しかし、それだけでは足りません。
テストがなくてもbuild passing
κeenさんのテンプレートエンジンのZenekindarl *1 もTravis CIでのテストが行われており、READMEに「build passing」という緑のバッジがありました。
しかし、じゃあ使えるのか、品質が高いのかというとそうではありません。当時はまだ機能を実装中でありテストもほとんどなかったのです。
このバッジだけでは品質の保証はできない。そこでテストがどれだけ書かれているかをカバレッジとして出すのはどうだろうと考えました。
他の言語ではテストカバレッジを表示するのにCoverallsというサイトを使っていました。Travisでテストを実行したときにカバレッジを計算し、JSONをCoverallsに投げることで表示されます。
Common LispはCoverallsではサポートしていないのでAPIを叩いてどうにか作りました。
それが「cl-coveralls」です。
カバレッジを表示することの意義
カバレッジは無意味だ、テストが十分かどうかはわからない、という意見もあるかと思います。もちろんそうです。けれど、無意味ではないと思います。テストが十分かはわからずとも、テストが不十分なときをいくらか拾えますから。
おわりに
cl-coverallsはGitHubで公開されており、Starは17ついています。
明日のアドベントカレンダーは23日目のPsychiqについてです。お楽しみに。
*1:当時はArrowsだったか
