プラグイン機構をそなえて、機能を追加しやすくするOSSがある。わかりやすいのはfluentdあたりだろうか。
で、何かのプラグインを作っており、かつ現役でしっかり使っているなら、元のプロダクト(コア)の更新時には自動で結合テストをしておくとよいという話。
プラグイン自体は単体テストをやってても、コア側に非互換の変更が入ったり、リファクタリングで機能に退行があると、結局バージョンアップ時に寝耳に水のようなエラーに会う。
結合テストを常にmasterのHEADで回しておくとコア側のアップデートを追いやすいし、もしかするとコア側でも『この変更で、既存プラグインは大丈夫だろうか(※)？』という不安が減るかもしれない。
※ そういう心配をするとこならある程度プラグイン用のテストも用意してくれていたりするが
しくみ
定期的に実行でもまあ悪くないけど、できれば細かい単位で回しておきたい。
サンプルとして、Chefのプラグインのこれを例に。
knife-zero/integration_testedge
IFTTTでmasterのcommitフィードを購読
プラグインの元プロダクトのmasterブランチでのコミットをfeedで受け取るには一覧に.atomをつける。
https://github.com/chef/chef/commits/master.atom
ついでにその他取れるフィードについてはこちら。
- Githubが結構色々なatomフィードを出せるので、連携で役に立ったりする - Qiita http://qiita.com/sawanoboly/items/eddc1e230657184d5121
これをIFTTT(など)のfeedトリガーとして登録。
CircieCIのブランチを指定してビルドを実行するPOST
もともとHerokuのスケジューラで定期的にテストを実行していたのですが、ちょっと前にIFTTTがHTTPRequestを投げれる様になったのが大きい。
次のようなPOSTをFeed新アイテム登場時のActionに登録すればビルドしてくれる。
# POSTで
https://circleci.com/api/v1/project/higanworks/knife-zero/tree/integration_testedge?circle-token=${CIRCLECI_PROJECT_TOKEN}
ものによっては、テストケースをgistとかに置いておくとソースと分離できて良いかもしれない。
masterの更新をトリガーにすると
- プラグイン側のテストがコケる変更期間が限定できる。
- 変更が必要ならさっさと対応。
- コア側の(意図しない)退行を、リリース前にプルリクエスト等で直せる。
この変更期間を特定しやすいのが嬉しい。
そもそもそんなに互換性崩れるのか？っていうと、親プロダクト次第なのではあるが。この例のケースでいえば結構壊れる。
ただこっち(プラグイン)は野良なんだし、コア側に普段から互換性を意識させるってのは面倒になりそうで。
テスト勝手に回るから気にしないで、くらいが丁度いいね。
バージョンアップIssueの抑制
コア側更新の影響で変更をするケース2種を比べてみよう。
- 『なんかバージョン上げたら動かねーんだけど？』
- 『コアの新機能使いたいから対応しようよ！』
前者は原因の調査から入らなくてはならない。継続した結合テストではこれをある程度予防できる。
なによりこの類のIssueはモチベ的にわりとしんどい。
この記事で紹介しているやり方では、そもそも後者の事は考慮していません。
しかし前者のほうは、自分でもキャッチアップしていることもあるし、Issueが作られる際も、どちらかと言うとプルリクエストで来る傾向にある気がします。
Chefの例では、実際にコア側でのインターフェース変更、デフォルトオプション変更、リファクタリング時の退行、あたりで結合テストがFailした。
そのたびにプラグイン側で対応するか、コア側にテストケース追加するなどで、リリース前にこっそり直せてる。