2013.4.20 CI and Testing Unconference in Tokyo に参加してきました。
http://citcon-jp.doorkeeper.jp/events/3473
CI(Continuous Integration)やソフトウェアテストに関するアンカンファレンスです。
「アンカンファレンス」ってなんじゃ?って感じだったんですが、まあみんなで議論しようぜー、という会でした。
アンカンファレンスとは…?
まず集まった時に各セッションの議題/テーマ(?)をみんなで決めます。参加者から議論したいこと、発表したいことなどを募り、そのテーマの議論に参加したい人、発表を聞いてみたい人を募ります。
ある程度みんなが興味あるテーマをセッションとして決めます。
大事なのはみんなで決めること。参加者がテーマを挙げ、参加者でそのテーマについて議論するイベントです。
今回は20名程度だったので2セッションにわかれて進めることになりました。
ということで参加したセッションのメモなど。
#1 カバレッジは100%を目指すべき?
テストコードのカバレッジをどこまでやるの?っていう話です。
カバレッジと言ってもC0〜C2とありますので、まずはそのおさらいを有識者から解説。
通常「カバレッジ」というとC0(ステートメントカバレッジ)のことを言う場合が多いですよね。
(カバレッジの測定ツールなんかはほぼこれ)
でもテストってC0だけじゃ不十分に決まっていて…。なんて話はこのテーマとは違うので割愛。
- 100%にすることは難しいよね。コストとの兼ね合い重要
- アーキテクチャのレイヤによって目指す数値は異なる
- コードを引き継いだ時にテストコードがあると嬉しい。カバレッジが高いとさらに嬉しい。テストコードがないと困るし、ダメなエンジニアって思ってしまう。
- 誰のためのテストコードか
- 100%にすることは難しいが100%を目指す心意気は大事
現実として100%は難しい。だけど100%に近づける努力をすることは重要でしょう、というのが心に響きました。エンジニアとしてどれほど誠実に仕事をしているか、ということでしょうか。
#2 TDDのテストと品質保証のテストって違うよね…?
このテーマは個人的にもとても興味があり、いい議論ができました。
- テストコードを書くという取り組みは品質管理チームに説明が難しい。なんか噛み合ない。
- テスト計画や目指す品質のイメージがステークホルダーで違っている。だから噛み合ない。
- TDD(テストコード)は内部品質をあげる仕組みであり、品質保証の一部ではあるが位置づけは若干異なるのでは。
- 品質管理チームなどは「一緒のチーム」として活動すべき。開発側とムダな対立となるのは意味がない。
という感じで、品質に関する捉え方がプロジェクト全体で統一できていないとうまくいかないよね、という話が出ました。そりゃそうだ。だけど大事なこと。
#3 CIの導入の事例発表
渋谷界隈のServicerから事例の発表です。
リリースが頻繁にあるプロダクトだとやっぱCIは必須。
#4 テストの工数はどれくらい?
テストに掛ける工数はプロジェクト全体に対してどのくらい?っていう疑問から始まったセッションです。
全体の40%程度ってのが妥当。これはウチの会社でも大体こんな感じ。
でも標準って考えは危険でプロジェクトによってコンテキストは変わってくる。それぞれのプロジェクトでちゃんと考えることは大事。似たようなプロジェクトとか隣のプロジェクトとかと比較するのも大事。計測はできるならやろう。
で、話が途中から変わり「みんなテストファーストってできてる?」という話に。
できてる人は2〜3名(笑)
みんなテストコード書くけど正しいTDDにはなっていないようです。
でもTDDを試みることはメリットが多くあって、例えばテストパターンをコード書く前に考えるので効率的だったりする。
それって設計の一部だったりして、結局コードを書くことって設計/コーディング/テストを行ったり来たりすることなんだよね、ってことですよね。
モノを作るってそういうことのはずです。
#5 Fabric, vagrant, chef-soloを使った構成管理
ツールの名前を聞いたことあるくらいで参加したセッションです。
話についていくだけで精一杯。詳細は割愛。
本番とステージング、開発環境はなるべく同じOS(環境)にしたほうがいい…。
って僕は当たり前って思ったんですが、色んな都合でそうなっていないことも多いのでその差異を構成管理としてどう吸収するのかってのは課題でしょう。難しいみたいです。
#6 ダッシュボードの話
「スーツの人」に報告するためにイケてるダッシュボードってなんだ?
という発表でした。
http://www.slideshare.net/ar_maniacs/ss-19250545
普段はダッシュボードって面白いなーと思いながらもそれほど関心を持たなかったのですが、可視化という点でもうちょっと注目されてもいい分野だなと思いました。
- インフラの状況(ネットワーク、リソースなど)
- 開発の途中(品質、進捗)
- サービス後(アクセス数、SEO)
それぞれのステージで見たいものは異なりますので使うツールもそれによって違いますよね。
なかなかぴったりくるツールはないようです。