hachiNote

勉強したことをメモします。

TDDBC札幌1.5に参加してきました

TDD Boot Camp 札幌 1.5に参加してきました(TDDとはテスト駆動開発の略です)。
テストは最近自分の中で関心度が高い事項だったので、Javaはほとんどやったことないけど思い切って参加してみました。

@shuji_w6e さんによるセッション

  • ソフトウェアは想像以上に複雑、完璧な詳細設計はほぼ不可能
    • 詳細設計のテストにならず、実装のテストになってしまうことも
  • TDDにおけるユニットテスト
    • 実装ではなく設計をテストする
  • 現代ソフトウェア開発の三本柱
    • バージョン管理、テスティング、自動化
  • テストの成熟度 - Boris Beizer
    • レベル0:デバッグするだけ
    • レベル1:動くことを確認
    • レベル2:動かないことを確認(何stepにつきバグ何件目標とかくだらないよねという話も)
    • レベル3:不具合の危険を許容範囲にする
    • レベル4:テストは品質を高めるための規律
  • テストの分類。誰が何のためにという観点で3種類
    • Developer Testing(機能を見る)
    • Customer Testing(進捗目的)
    • QA Testing
  • テストというべきでないという人もいる(BDDとか)
    • 設計の側面もある
  • テストの三要素:Test Case, Expected, Actual
  • 4-Phase Test: Setup, Exercise, Verify, TearDown
  • テストはサンプルコード
  • テストはドキュメンテーション
    • 検証可能なドキュメント
  • テストケースの独立性大事
    • DBアクセスが入ると遅くなるので、並列処理によるテスト実行とか

@shuji_w6e さんによるセッション その2

  • テスト駆動開発
  • TDD三原則 - Uncle Bob
    • 失敗するテストコードより先にプロダクションコードを書いてはならない
    • テストケースのコンパイルが通り、適切に失敗するまでは次のテストケースを書いてはならない
    • すべてのテストケースが成功するまでは次のプロダクションコードを書いてはならない
  • きれいな動くコードへの道
    • 設計する
    • テストを書く
    • コードを書く
    • テストを成功させる(最短コースで)
    • リファクタリング
    • また設計する(繰り返し)
  • TDDのこころ
    • 小さく
    • 一人ずつ仕留める
    • 素早く回す

デモ、演習で知った雑多なメモ

  • テストリストをまず作成し、それを1個ずつやっつけていく
    • 最初から全部リストアップする必要はない。必要になったらまた足していく
  • 1つのテストに取り組んでいるとき、「あ、あれも実装しなきゃ」と思っても寄り道しない
    • そのテストを終わらせてから次
  • テストリストのなかに、このクラスを作成する、みたいなものも入ってくる
  • Ecripseの操作方法覚えるの大事だ
    • コマンド+0でテスト実行
    • コマンド+1でQuickFix
    • コマンド+9でプロダクションコードとテストコードとの行き来
    • プラグイン入れればEcripseから簡単にコミットできる
  • 1サイクルまわしたらコミットしよう
  • テスト駆動開発入門という本があるよ

感想、疑問

  • テストコードを書いたあと、まず最短でテストを通すコードを書く意味は? いきなりちゃんとした実装コード書いちゃだめなの?
    • shujiさんは、「それが後々大きな意味を持ってくる」とおっしゃってたが、詳しく聞きそびれた
    • 感覚的にはそれは間違っていない気もするが、自分のなかでちゃんと説明できない
  • 単純に、短いサイクルで、赤になったー、書いてみたー、緑になったー、動かないー、動いたーってやるのって、楽しい。
  • ペアプログラミング楽しい。みんな優しい。教え方うまい
  • もっと設計的なところまで議論してみたかったが、時間が足りなかった

参加した目的だったこと

仕事でTDDをやらされていたが、どうもその内容があまり意味がないように思えて、ずっと「本当はもっと正しく、意味のあるやり方があるはずだ」と感じていた。

その業務でやらされていたTDD(と言われていたもの)はこんな感じ。

  • クラス図、クラス詳細(プライベート含めた全メソッド)、メソッド1件1件のセマンティクスをかき、そのセマンティクスに基づきテストケースを書かされた
  • でもコードを一行も書いていない時点でのメソッド1件レベルの設計が全部正しいはずがない。でもサイクルをまわすという概念はない
  • しかも間違っていたことに気がついてテストケースを書き直したら、Roseに書いたセマンティクスも書き直さなきゃいけない(同じ内容なのに)
  • プライベートメソッドもテスト対象
  • テストの確認は、そのメソッドからコールするはずのメソッドがちゃんと呼ばれていることの確認がメイン
    • メソッドコール回数を確認するための仕組みを作っていた
  • このレベルのことをテストファーストで書くのはめちゃめちゃ難しい
  • 結局みんな普通に実装してからそれにあわせてテストケースを書いてた
  • メソッドコールの確認ががっちり含まれているので、少しでもコードいじったらとたんにテストNGになる
  • ものすごい時間を取られるわりには意味があるように思えなくて、モチベーションもあがらない

でもTDDBCに参加して、やっぱり違ってたんだなとわかってすっきりしました。今思えば、これまでやっていたのは、ユニットテストテストファーストでやろうとしていただけで、真のTDDではなかったんですね。

ユニットテストって、本当は開発者にとって安心と勇気を与えてくれるものなんじゃないかと信じていましたが、それが間違っていなかったとこの短い時間でも感じることができて、とてもうれしくなりました。

さらに最近思うこと

勉強会に参加するようになったのはごく最近ですが、どの勉強会に行っても思うことがあります。

  • みなさん話しかけるとにこやかにお話してくれる
  • できる人できない人みたいな差別を感じない(スキルの差を気にしていない)
  • 違う意見を言っても、いきなり否定せずに話し合い始める

あたりまえのようでこれはあたりまえではないと思うんです。

だって思い返してみてください。会社の人たちは、みんなこうですか?

なんで勉強会に出席するみなさんはそうなんだろうって、疑問に思っていました。

自分なりに考えてみたことは、みなさん自分の職種に誇りを持っているからなのかなーってことです。

この職種の魅力って、やっぱり新しいものを作り出していけるってことだと思います。その一生産者として、よいものを作りたいという想い。これは自分が作ったものなんだと自信を持って言いたいという想い。

その想いがはっきりしているから、他人の意見を受け入れたり、新しいものを取り入れたりすることにあまり抵抗を感じない。そういうことなのかなって、このごろ思います。

全然見当違いのこと言ってるかもしれませんが、そういうのってすてきですよね!