「ホワイトボックス単体テストにおけるペアテスティング」を読んで

"ホワイトボックス単体テストにおけるペアテスティング" 第20回 ソフトウェア工学の基礎ワークショップ FOSE 2013 in 加賀（ショートペーパ採択）http://t.co/teiEFk2vX1

— Hironori Washizaki (@Hiro_Washi) August 30, 2013

上記のツイートを見て興味があったので読んでみました。
感想とか気づきのまとめ。

ペアテスティング

ペアプログラミング、と同じ感じだよな、と直感的にわかりますが、Googleさんに聞くとテスティング・ペアとかも出てきてます。
ペアでテスト設計したときの品質に与える影響、および方法、最も良いテスト品質を実現するには？というあたりが、このペーパーの内容です。
また、テストコードでのホワイトボックス単体テストを対象としています。他のテストレベルだったり、ブラックボックステストだったりすると、変わってくる部分、同じような結果になる部分がまた出てきそうだなと思いました。

テストカバレッジ

テストカバレッジが高いほど欠陥検出力が高い、という引用があります。
ここではホワイトボックス単体テストなのでコードカバレッジなのですが、テストカバレッジってコードカバレッジだけなんだっけ？と思いJSTQB用語集を見ると、coverage参照となっていて、

指定の網羅条件をテストスイートが実行した度合い。パーセンテージで表す。

となっていました。コードカバレッジは別であったので、限定的なものではないなと再確認。

ミューテーション解析

ミューテーション解析は、初めて聞いた言葉でした。テストコードの妥当性をどう担保するのか、というのはいつも説明が難しいところでした。
JavaやJavaScriptでもツールがあるようですし、Jenkinsのプラグインもあるようなので、今後使ってみたいなと思いました。

検証結果

検証の結果は予想を覆すもので面白いと感じました。特に、被験者がやりやすいと感じた「ペア１台」の方法が必ずしもテストコード品質につながっていない、というところです。
先日TDDBC Boot Camp長岡1.0でペアプロしたときに「やりやすさ」だったり「楽しい」ということ感じましたが、ペアテスィングでも同じ傾向がある気がします。
ただ、必ずしも品質につながっていない、というのはペアプロも同じで、こちらはいろいろな研究がなされていることが書かれています。
ツールとしてのペア作業も、条件下にあった形で行う事で生産性や品質に及ぼす影響が大きく違うんだと、なんか当たり前のようななんだけど、感心しました。
また、そういった研究が行われているのであれば、実際の作業に活かしていく事が重要だなあ・・・って、思いました。行われていることすら知らなかったという・・・ですが。

その他

こういうペーパーを読んでないのがバレバレですが、「妥当性の脅威」、「まとめと今後の展望」という章があり、気になったところに触れられていて、今後も気になりました。
あと、こういう研究でプラクティスへの裏付けがとられていく事は長期的にとても重要だし、すでに研究されていることを活かす事も必要だと改めて感じました。
SEMATもこういう部分をどうにかしていくものなんだと思ってます。

Niigata.rb #3 に参加してきました。 #niigatarb

新潟のRuby勉強会「Niigata.rb」に参加してきました。
RubyといえばRedmineのプラグインもやっている・・・というか、すがる思いで申し込みましたw
場所は、新潟市中央図書館「ほんぽーと」。私が8/31現在メイヤーな、行きつけの勉強スポットでした！ああいう会議するところもあるんですね。
@dictav さんをはじめ、みなさまありがとうございました。

例によってアジェンダに沿って振り返ります。

Niigata.rb について

るびこさんがマスコットな、Niigata.rbは第３回。
NDSでrubyな人たちが新潟にもいる！というところから、はじまったそうです。
今回は半数ぐらいが県外勢でまたびっくり。学生さんも多かったです。

テスト駆動開発は みんなの心の中にある (@kenchanさん)

TDDBC 長岡1.0に続き、くるものがあるお話でした。

• 「複雑」には「Complicated」と「Complex」がある、「Complecated」な複雑は分解して一つずつ相手にするとテストが書きやすくなるというのは、なるほどなあと思いました。小さな問題にして、というのがもう少しクリアになった感じがしました。
• 角谷さんのお話からとのことでしたが、コードにした事だけではなく、コードにしなかった事も含めてプログラミング、という話がありました。いろいろな方法から選択した理由、選択しなかった理由を捉えて、初めてコードを作っていると言えると思います。
• TDDBC 長岡1.0 Reloadedは、自分も参加して言語は違えどやったお題だったので、なるほどなるほどと思いながら聴いていました。

初心者向けrubyの実行環境構築 (@kasacchifulさん)

Windows、Mac、Linuxでの実行環境構築のお話でした。
rbenvでのバージョン切り替えなども含んだ実践的な内容でした。
私はLinux環境でやってた頃はrvmでしたが、最近はrbenvでやってます。bundlerがあればrbenvかな、と思ってます。

エモい話かなにか（@upinetreeさん)

TideSDKというHTML5からRubyを扱いつつ、ネイティブアプリになるっていうフレームワーク？のお話でした。
艦コレ・・・なにこれ？の私には今ひとつ笑うタイミングが掴めませんでしたがw、簡単な指定で使える事、ネイティブアプリにできることは面白いと感じました。
艦これランチャーw

RubyMotion (@jewel_x12さん)

まさか、ここでつくる！？という艦コレな流れでもうwwwな、RubyMotionのお話でした。
実際にその場でライブコーディングされて、まあなにがってすごいですね、プレゼン。
テストコードの中でtapなんかもテストできるようで、面白いなと感じました。
スタイルシートみたいな感じでレイアウトができる、というのは、なんとなくVBのフォームのソースファイルを思い出しました。なんでだろ？

Redmineプラグインのテスト書いてもらえませんか？(@two_pack)

私の発表。書いてもらえませんよ、というのが答えのようですorz
RedmineのXLS Export Pluginをなんでいじっているか、という話と、誰かテスト書いてよ〜という他力本願な感じの内容でした。
真剣にxlsx exportに書き直す事を考えた方がいいのかな・・・

LT！（みなさま）

開始冒頭に「みなさんLTするってことで」的な話から「まだ発表していない人」的な流れで、みんなLTでしたww
みなさん興味深い話が多かったのですが、やはり@jewel_x12さんの「小指が痛いのがRubyのせい」っていう、３段論法的なLTが興味深いを通り越してましたw
@mihyaeru21さんのRubyのコーディング規約の話は、そういうの決まってるのか！確かにそうだ！と勉強になりました。
@bei_kanさんの「組み込みだからこそTDDで書く」という話は、とても心を打ちました。

まとめ

艦コレやらないとだめなのか、、、そうなのか、というNiigata.rbでした。アンテナ高くしていきたいと思いますw