読者です 読者をやめる 読者になる 読者になる

プログラミングの魔物

エラー、バグ、仕様変更と戦うブログ

テストの構築

リファクタリング 4章

テストを作るとプログラミングが加速する。
※ただしゲームの場合は難しい。あくまでテストの自動化が可能なコードにおける話。

自己テストコードの意義

  • プログラミングはデバッグにかかる時間が多い
  • クラス自身にテストさせる(testメソッド)
  • テストの成否もコンピュータにやらせる(上手く行けば「OK」)
  • コンパイルする度にテストが実行される(エラーが起きれば今書いた部分)
  • もうデバッグなんて怖くない
  • 手動でデバッグなんてやってられない
  • テストから書き始める(これから何をするのか自問できる。インターフェースに集中する)
  • クラスにテストを導入する以外にテスト用のmainを作る方法と、テスト用クラスを別に設ける方法がある

JUnitテストフレームワーク

JUnitJava単体テストフレームワーク
他の言語にも*Unitフレームワークがあることが多い。

  • TestCaseを継承してテストを作る。Composite構造でTestSuiteにまとめられる
  • まずはテスト対象を準備(テスト例となるオブジェクト)
  • TestCaseクラスはテスト対象を操作する2つのメソッドを提供する
    • setUpメソッドはオブジェクトを作成する
    • tearDownメソッドはそれらを削除する
  • テスト対象の準備ができたらテストを書く。結果をassertでチェックする
  • 最後にテストスイートを作成する
  • TestRunnerでテストを実行する

1日に最低1度はすべてのテストを実行する。

  • リファクタリング中はテストを限定する
  • テストを書く際に、初めは失敗するようにする(テストが実行されるかどうかの確認)

単体テストと機能テスト

  • 機能テストはソフトウェア全体の動作
  • 機能テストはブラックボックステスト
  • バグを見つけたらバグを明らかにするための単体テストを書く。関連する不具合があれば複数のテストを書く。バグを突き止めるのにも、同じようなバグをすり抜けさせないためにも有効

テストの追加

  • アクセサなどの単純なメソッドにまでテストを追加する必要はない
  • 一番怪しいものをテストする
  • テストを書いてテストスイートに追加する
  • 毎回テストケースを追加するのは面倒→testから始まるすべてのメソッドをテストスイートに追加するオプション
  • 境界値テスト、特殊条件、テストケースで新たにオブジェクトが必要になればsetUpで作る
  • どうすればバグを潰せるか、意地悪な気持ちで取り組む
  • 予想されるエラーが正しく起きることの確認
  • テストでプログラムにバグがないことは証明できないので、適当な所で切り上げる。怪しい部分には配置する
  • ほとんどのバグはテストで見つかるので、テストを書くのを止めない

メモ

  • assertをまめに入れる

この記事で読み進めている本

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 91人 クリック: 3,033回
  • この商品を含むブログ (295件) を見る