ケロSE

ケロいSEが日々思う事を書きます

JJUG CCC 2014 Spring に参加しました。

JJUG CCC 2014 Springに参加しました。

メインはTDD BootCamp in JJUG CCC -レガシーコード対策ハンズオン- をTAとしてお手伝いすることでした。

渡辺 修司さん(@shuji_w6e)の講演のスライドはこちら。

Java使い必携の書、JUnit実践入門が4刷、累計１万部突破めでたい！

TAとしてウロウロしている間に参加者の方が質問してくださった事に対して私がどんな回答をしたかをシェアします。

  1. 今の課題はプロダクションコードが既に出来上がっている状態なので、本来のTDDのサイクルがいまいちピンとこないのですけど、本来のTDDはどういう風に進めるものなのですか？
    • 一番シンプルなケースから実装していくので、まず最初は消費税率が0%の時に金額が計算できるテストを書いて、そのテストがクリアしたら、リファクタリング、次は消費税が5％の時のテストを書いて、そのテストもクリアするように実装を変えて...のように進めていきます。(この疑問はフルバージョン？のTDDBCでペアプロのデモを見ていただけると 解決するかも) 本来のTDDのサイクルを体感するのだと、今のプログラムに機能を追加する(例えば商品10個以上買った時は割引になるとか)のを、まずテストから書いてみるとかどうでしょう。
  2. Order#orderメソッド（注文）の注文数が負数になった場合は不正な処理として例外を発生させるようにしたいのだけど、TDD的にこれはどう進めるのが良いですか？教科書通り先にテストを書くのですか？先に実装を書くのですか？
    • やりやすい方で良いと思います。JavaはRuntimeExceptionが予期せぬ箇所で発生する場合があるので、教科書どおりに最初に「IllegalArgumentExceptionが発生する」テストが失敗させてからプロダクトコードを変えてテストを成功させた方が安心できる気はします。好みや慣れの問題もあるので、どうしても先にテスト書かなきゃだめ、ってことはないです。(あくまでコーディングを快適に進める為の手段なので、先にテスト書くのが重いなら後まわしでも良いかと(
  3. 注文時に設定する消費税率の上限はどこまでテストするべきでしょうか？ 消費税率100％のようなケースがいるかと思ったのですが、よく考えると不要かな？と思えてきて...
    • TDDでは「不安をテストにする」という言葉があるので不安であればテストを書いて良いと思います。のくらいテストをすれば十分か、はテスト技法を学ぶと良いと思います。消費税率が100％以上になると計算方法が変わる等であればテストすべきですが、特にそういう物でもないので私は無くていいと思います。
    • この質問はちょうど渡辺さんも聞いていて「もう1つ、補足として、明らかな異常値をエラーにするような実装をしておくのも現場では必要になるかも。そういう作りにしておくと、某株式の誤発注事件のような事件が防げます。システムがしばらく止まるのと、会社の経営が傾くのとを秤にかけたら、後者を選びますよね。」のように仰っていました。

と、誤発注をテストで防ぐ、のような話を聞いたあと、お酒の過剰発注が明らかになったお陰で楽しく懇親会に参加させていただけましたｗ。