ReadingAgileSamuraiInActsystems20130408

← ReadingAgileSamuraiInActSystems

第24回 アジャイルサムライ読書会 in アクトシステムズ道場

日時: 2013年04月08日 12:05-12:55

参加者: 5名

第12章 ユニットテスト：動くことがわかる

◆ 12.1 ラスベガスへようこそ

ユニットテストって書いてる？

• 書いたことが無い人がほとんど

TDDってどういうの？

• 概要は知っているけど、実際書いたことないのでイメージがわかない。
  • 仕様をコードとして初めに書くってことです。
• 始めにテストを書くってどういうこと？
  • プログラムがこう動くはずという検証コードを実装前に書く
  • テストコードにはそういった記述ができる
  • 例：１日の日報の時間を検証するプログラム
    • 仕様：作業の集計時間が８時間であること。
    • テストコード(＝サンプルとか言ったりする）
      • サンプル１
        • 作業時間 = [8]
        • 作業時間検証(作業時間) == 'OK'
      • サンプル2
        • 作業時間 = [7]
        • 作業時間検証(作業時間) == 'NG'
• 基本的にはTDDは製造を助けるもので品質保証ではないです。
  • ただし、TDDをちゃんと実践すると品質は手動テストより上がります。
    • 出来上がったテストコードは回帰テストの自動化に利用できます。
    • １ステップ直しただけで全てのテストパターン検証します？
      • 手動テストだとコストがかかり過ぎてしてないでしょ？それがTDDだと出来るようになります。
      • 稀に修正後に１回でもテストしとけば発見できたのに的な不具合が発生したりしますよねぇ？そういったの救えます。
• テストフェーズを省けるわけではないです。
  • あくまでテストコードで記載していることを保証するだけです。
  • 仕様から最低限保証しないといけない部分はテストコードに書いて保証できます。
  • テストコードに記載できることは自動化で保証して、人間しかできないテスト（探索的テストなど）に多くの時間を掛けようという考えです。
• TDDの話しだけで１日は十分話せる内容なのでこれくらいで切り上げます。

どんな言語に対応してる？

• 最近主流の言語なら大概対応してるはず。
  • ruby, java, .net
• うちの主流言語で対応してないのはCOBOLとASPぐらいじゃないかな？

◆ 12.2 はじめてのテストユニット

怪しい所をすべてテストする。

• 的外れなテストは書かない
  • 例えば、内部的なインターフェースなどのテストを沢山書いてもしょうがない
    • テストで不具合を発見できるケースは稀だし、逆に変更時にテストコード修正にコストがかかってしまって効率が悪い。

TDDで開発するのにテストコード記載する工数積んでる？

• 製造の効率を上げる手法と考えているので特別工数は積んでないです。
  • 今までの方法で開発する時には何度も実際に動かして何度も目視するでしょ？
    • 場合によってはデバッグ用にコード埋め込んだりして確認してるでしょ？
  • TDDは目視の代わりにコードとして記載してテストにパスするかチェックするのです。
    • 従来の手法でも実装コードを記載する時間はそんなに変わらないと思ってます。
  • TDDで実装しているおかげでデバッグ時間が短縮したりすることもあります。
• TDDを実践するには記述方法など余計に学習する必要はあります。

なんでTDDの事例が社内は少ないの？

• 知らない？興味ない？
  • アンケート取ってみたら？
• 全社的に取り組まないといけない課題じゃないの？
• 「３０分でわかるシリーズ」をTDDでもやってほしいな。

---

次回 2013年04月15日(月) 12:05〜12:55