第5章:ツール

はじめに

リファクタリングツールの利用による自動リファクタリングの利点と考慮しないといけない点についての説明。
そして、自動リファクタリングをする際は、それによる既存の振る舞いが変わってしまわないことの確認が必要であることの説明がされている。
その確認のためのテスティングフレームワークについての説明がされている。

リファクタリングツール

■利点
リファクタリングツールを使うことでリファクタリングの作業はとても容易になることが期待される。


■考慮すべきこと
ツールによってサポートするリファクタリングのレベルはまちまち。
リファクタリングツールによる変更を行う際は、それによって振る舞いが変わらないことを検証するべき。
Bill OpdykeのSmalltalkリファクタリングブラウザをはじめとして、初期の多くのJavaリファクタリングツールもそうだった。

主流でないツールの中にはそのチェックをきちんと行ってくれないものもある。
結果、リファクタリング時にバグを作りこんでしまうこともありうる。


■著者が新しいリファクタリングツールに出会ったときに検討すること

  • メソッドを抽出して同じクラスにもともと存在するメソッドと同じ名前を付けたときにエラーになるか。
  • 基底クラスのメソッドの名前を付けた場合にきちんと検出してくれるか。

検出してくれないのであれば、メソッドのオーバーライドによってコードを壊してしまう危険がある。


リファクタリングツールを適用した例と心得
<適用前>
getValueメソッドが実行されるのはループに入る前の1回だけ。
変数alphaは1回だけインクリメントされる。

<適用後>
getValueで返される値が12で固定だからか、ループ内でgetValueが呼ばれるようになった。
結果、変数alphaはループ回数である10回インクリメントされる。
 ⇒既存の振る舞いが変わってしまう。

<心得>
自動リファクタリングを始める前には、自分のコードに対するテストを準備しておくことが大切。
テストなしで実施できる自動リファクタリングもあるが、ツールが何をチェックして何をチェックしないかを確認する必要がある。

モックオブジェクト

テスト対象クラスが依存している別のクラスに、自分のコードをテストするために正しい値を返すようにするためのオブジェクト。

単体テストハーネス

GUIやWebインタフェースを使ってテストするツールはあるが、思っている以上に大変。
 ⇒そのツールのラーニングコストとか導入とかに時間をとられるから?
UIはたいていテストを書くのに適した場所ではない。
 ⇒UIは変更されることが多く、テスト対象の機能から離れすぎているから。
  UIベースのテストが失敗したとき、その原因を解明するのは困難。

書籍ではxUnitテスティングフレームワークについて述べられている。

  • プログラマは自分が開発に使っている言語でテストを書ける。
  • すべてのテストは独立して走る。
  • テストをスイートにまとめ、要求に応じて実行/再実行することができる。

※テストスイート:ソフトウェアテストの目的や対象ごとに複数のテストケースをまとめたもの。
https://www.itmedia.co.jp/im/articles/1111/07/news187.html


JUnit
JUnit3を使ったコードの説明。
ただ、「TestCaseクラスのサブクラスとすること」「メソッドの先頭を"test"とすること」という制約は、JUnit4で廃止されている。アノテーションを利用する。

@Beforeアノテーション

  • public voidなメソッドに付与することで、各テストメソッドを実行する前に集実行してくれる。
  • JUnit3におけるsetUpメソッド。

setUpメソッド

  • テストメソッドを実行する前に各テストオブジェクトで実行されるメソッド。
  • TestCaseクラスに定義されているメソッド。

@Afterアノテーション

  • public voidなメソッドに付与することで、各テストメソッドを実行した後に都度集実行してくれる。
  • JUnit3におけるtearDownメソッド。

tearDown

  • 各オブジェクトのテストメソッドの後で実行される。

テストの実行が終わった後で何か特別な処理をする必要がある場合はこのメソッドを呼ぶ。

  • TestCaseクラスに定義されているメソッド。

@Testアノテーション

  • public voidなメソッドに付与することでJUnitにテストメソッドであると認識させる。

参考:https://qiita.com/tsukakei/items/b892409cf982f1951933


JUnit以外のテスティングフレームワーク
CppUnitLineとNUnitは省略。
それ以外のフレームワークについては以下を参照。
www.xprogramming.com
※Softwareセクションを見るように書かれているが、アクセスしてみた感じ、見当たらない。

FIT(Framework for Integrated Test)
統合テスト用のテスティングフレームワーク
システムに関する文書を書き、その中にシステムの入力と出力について記述した表を含めることができれば & その文書をHTMLとして保存できれば、それをもとにFITフレームワークがテストを実行してくれる。

ソフトウェアを書く人とソフトウェアが何をすべきかの使用可を担当する人の間のコミュニケーションを促進できる。

参考: http://fit.c2.com

Fitnesse
wiki上に構築されたFIT。
参考: http://www.fitnesse.org

まとめ

以下の内容についての説明がされている。

  • そして、自動リファクタリングをする際は、それによる既存の振る舞いが変わってしまわないことの確認が必要であることの説明。

FITは使ったことが無いのでわからないが、結局「どの粒度でテストをするかに応じてxUnitを使うのか、FIT(またはFitnesse)を使うのか」が変わる認識。
単体テストなのであればxUnitを使ってテストすればいいし、受入テストレベルであればFIT(またはFitnesse)でテストすればいい。

FIT自体初めて聞いた言葉なのでこれについては調べてみるのもいいかも感。