Google Test と Travice CI で、C言語で書いたライブラリの継続的インテグレーションをしてみた結果
結果
たのしい！
出来上がったものはこちら。
以下、行ったことです。
C言語で Google Test を使う
Google Test はC++で書かれている単体テストライブラリです。
C++で書かれている、ということで、気合いを入れればC言語でも使えます。
とは言っても、入れる気合いは
extern "C" { #include ( C のヘッダファイル) }
これだけでした。
後はマニュアル通りにGoogle Testを使った単体テストを書きます。
テストコード書いて、
ダミー実装して、
レッド出して、
ちゃんと実装して、
グリーンにする。
全部の関数が出来上がらなくてもテストは走るので、必要な関数が全部出来上がるまでテストできない！ なんてフラストレーションを抱える必要もありません。
楽しい。
Travis CI で Google Test を使う
Travis CI とは、Githubと連動した継続的インテグレーションサービスです。
具体的には、Githubへコードをプッシュすると、予め指定しておいたテストをTravisが実行し、結果を教えてくれる、というサービスです。
当然、複数人での開発で効果を発揮しますし、自分のプロジェクトがテスト通過済みである、ということのアピールにも使えます。
easylogging/easyloggingpp · GitHub がTravis CIでGoogle Testを動かしていたので参考にさせていただきました。
ポイントは以下。
Google Test のインストール
aptitudeでインストールできるようです。
そしてその後ビルドが必要。
- sudo apt-get install libgtest-dev - "cd /usr/src/gtest && sudo cmake . && sudo cmake --build . && sudo mv libg* /usr/local/lib/ ; cd -"
これでテストコードからは#include <gtest/gtest.h>でヘッダを参照できますし、
コンパイラから -lgtest で参照できます。
Google Test 的には「このライブラリをシステムにインストールしない方が良い」としています。
テストを行う環境毎に Google Test のバージョンが違う、などということを避けるためらしいです。
が、Travisならテスト毎に仮想マシンがリセットされるので心配ありません。
はまった箇所
ビルド時の -lgtest の引数位置
clangの使い方を分かっていないだけでしたが。
.travis_build.sh の4行目。
自分で用意したテストコードと gtest のバイナリをリンクする際。
clang++ -std=c++11 -g -Wall -Wextra -o unit_test set.o unit_test.o -lgtest -pthread
のように、-lgtest をテストコードより後に持って来ないと
/home/travis/build/kikuchy/SmallSet/test.cpp:10: undefined reference to `testing::internal::AssertHelper::AssertHelper(testing::TestPartResult::Type, char const*, int, char const*)'
といった感じで undefined reference のエラーがダバーっと出て来てリンクに成功しませんでした。
まとめ
巷で騒がれている継続的インテグレーション（CI）。
オンラインでテストが出来る、テスト通過済みである事を証明できる、という利便性もさることながら、みんながCIを行う一番の理由は、
楽しいから
だと思いました。
通常一人でプログラムを書いていたりすると、ある一つの主だった機能を実装するまでプログラムがきちんと走り切らない、またはコンパイルすら通らない、ということが往々にしてあります。
しかし、テストをちゃんと書いていれば、小さな機能ごとに動作を確かめることができます。
どこまで実装が終わったのかも、グリーンの数でわかります。
小さいながらも続けて達成感を得ることができるので、ついつい「もうちょっと、もうちょっと」とコードを書く手を止められませんでした。
それに何より。
Readmeに輝く "build passing" のバッジが誇らしい！！
開発したライブラリについてはまた後日。
