1. リファクタリング
プログラミングの体質改善テクニック
読書会
2012/02/20

2. 第4章 テストの構築
• 堅実なテストは、リファクタリングを
する上で欠かせない事前条件
• よいテストを書くとプログラミングが
加速する

3. 自己テストコードの意義
• プログラマの大半が実際にコードを書
いている時間は短い
• 多くの時間をデバッグに費やしている

4. テストの自動化
• テストを完全に自動化して、その結果
もテストにチェックさせる
• テストを頻繁に実行しておくと、バグ
検出に絶大な力を発揮する
• バグの発見にかかる時間が削減

5. 機能追加はテストから書く
• 機能を追加するためになすべきことを
自問することになる
• 実装よりもインターフェースに集中する
ことになる
• コーディングの完了時点が明確になる
→テストがうまくいったとき

6. JUnitテストフレームワーク

7. テストクラスの作成
• テストを内包するクラスは、TestCaseク
ラスを継承しなければならない
• TestSuiteクラスにひとまとめにして入れ
ておくことができる

8. テスト対象（test fixture）の準備
• テスト対象を操作するメソッド
• setUp
• tearDown

9. class FileReaderTester extends TestCase . . .
protected void setUp() {
try {
_input = new FileReader(“data.txt”);
} catch (FileNotFoundException e) {
throw new RuntimeException();
}
}
protected void tearDown() {
try {
_input.close();
} catch (FileNotFoundException e) {
throw new RuntimeException();
}
}

10. テストを書く
• assert（表明）メソッド
• 真なら正常、そうでなければエラー
を通知

11. class FileReaderTester . . .
protected void testRead() throw IOException {
char ch = ‘&’;
for (int i = 0; i < 4; i++)
ch = (char) _input.read();
assert(‘d’ == ch);
}

12. テストを実行
• テストスイートの作成
• テストケースを指定
• TestRunnerで実行

13. class FileReaderTester . . .
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new FileReaderTester(“testRead”));
return suite;
}
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}

14. 【実行結果】
.
Time: 0.110
OK (1 tests)

15. class FileReaderTester . . .
protected void testRead() throw IOException {
char ch = ‘&’;
for (int i = 0; i < 4; i++)
ch = (char) _input.read();
assert(‘2’ == ch); //故意のエラー
}

16. 【実行結果】
.F
Time: 0.170
!!!FAILURES!!!
Test Results:
Run: 1Failures: 1Erors: 0
There was 1failure:
1) FileReaderTester.testRead
test.framework.AssertionFailedError

17. • テストを書く際は、初めは失敗するよ
うにしておく
• 本当にテストが実行され、期待どお
りにテストしているかを確認するため

18. 単体テストと機能テスト
• 単体テスト：プログラマの生産性を向上する
ため
• 機能テスト：ソフトウェア全体の動作を保証
するため

19. バグを発見したら
• まずはバグを明らかにするための単体テスト
を書くべき
• バグを突き止めるのにも、再度おなじバグ
が単体テストをすり抜けないことを保証す
るのにも役立つ

20. テストの追加
• 一番怪しいと思う部分をテストする
• 失敗の恐れのある境界条件を考えて、
そこを集中的にテスト
• 予想されるエラーが正しく起こること
の確認を忘れない

21. やめ時はいつか
• 過剰なテスト
• やる気が失せて、何も書けずに終わる危険
• リスクがどこにあるか注目すべき
• コードを見て、複雑になってくるところ
• 機能をみて、エラーが起こりそうなところ