DevLOVE関西 自動テストの誤解とアンチパターン 2014/4/19

4/19に、DevLOVE関西 自動テストの誤解とアンチパターンに参加しました。

申し込み開始当初、すぐにいっぱいになり、参加を諦めていたんです。でも、2日前くらいに、一応キャンセル待ち登録しておいたら、なんと増席で参加できるようになって、これは行くしかないと。

開始早々、きょんさんがまだ到着しておらず、DevLOVE関西と会場提供のはてなさんから、場つなぎ。そうこうしているうちに、きょんさんが到着。うさみみを装着し、先々月のTech Talkの時の発表をベースにした発表が行われました。:資料

特に印象に残ったことを書きます。

  • テストの取り組みについて

    普通の人は、思ったほど当たり前に勉強するわけではないし、意味のあるテストを効率的に書くことができるスキルがあるわけではない。チームとして、それにどう取り組むのか。統合テスト自動化で得られる最大のメリットは「テスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」。
    →現実問題として、できる人と、できない人がチームにいるので、後者が前者になっていく過程で、必要な技術を習得するためのプラクティスとして、使わない手はないですね。


  • 効率的な自動統合テスト

    「プロダクトコードをレビューできるスキルがないなら、効果的な自動統合テストは不可能に近い。」
    →その通りだと思ったけれども、なかなか難しいところ。コードレビューもテスト設計もできるけれども、不要なケースを省いたり、効率的に実施するのは別スキルだなという感覚があります。一人一人が全員できるようになるというよりは、チームで知恵を絞ってやる方が現実的かなと思いました。


  • テスト自動化の実践に関して

    Excelなどでテストケースを納品する必要があるようなケースでも、Excelは後から生成するなどの方法で、テスト自動化を実施。
    →ここは、まだできることがあるのに、自分が変に諦めてしまっているところがあるなと気づきました。



その後の、ワークショップは、「TDD」をテストコードとして表現してください、というもの。本質を突き詰める、きょんさんらしいワークショップでした。
おおよそ、開発者がテストによりその考え方が正しいか否かを確認する、というシンプルなものでしたが、自動統合テストにしろ、開発者が、ユーザーの振る舞いをシミュレーションするものだと思うので、そこに行きつけば、そういうことかと納得できると思いました。

その後、shibuya_yu36さんによるセッション「課題をテストで解決する」、hakobe932さんによる、Coding Kata実践が行われました。

課題をテストで解決するの方は、かなりヒットでした。人が気をつけるのにも限界があるので、テストでカバーしましょう、と。Coding Kataの方も、あの状況でプログラミングをするというのは、ペアプロなどとは桁違いのプレッシャーだと思いますが、平然とやられていてすごいなと。内容もよくわかりました。

最後に、ダイアログで、各テーマ毎に分かれて話をしました。私は、課題の自動化(による解決)について興味があったので、そのグループで話をしました。自動家の@kazuhito_mさんがまとめてくださいましたが、
・(テストコードがないという意味で)レガシーコードの対応や、デグレードに悩んでいる組織が多そう。
・コード以外のことも自動化で対応したい妄想にある人がこのグループに集まったっぽい。
・作業は、まず無くす努力→だめなら作業自動化→難しければチェック自動化→職人による目検は最後の手段
・(昔ながらの)職人がいると、あかん自動化(人がみた方が確実、みたいな、自動化ではないところ)に進む場合がある。でもそういうところこそ自動化必要疑惑あり。
のようなところで時間切れ。

5/18に名古屋でTDDBCあるので、そちらでさらに手を動かしながら、学ぶことができればと思います。