• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
リファクタリング読書会20120220
 

リファクタリング読書会20120220

on

  • 1,396 views

 

Statistics

Views

Total Views
1,396
Views on SlideShare
718
Embed Views
678

Actions

Likes
1
Downloads
2
Comments
0

3 Embeds 678

http://ameblo.jp 604
http://blog.ameba.jp 60
http://s.ameblo.jp 14

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

リファクタリング読書会20120220 リファクタリング読書会20120220 Presentation Transcript

  • リファクタリングプログラミングの体質改善テクニック 読書会 2012/02/20
  • 第4章 テストの構築• 堅実なテストは、リファクタリングを する上で欠かせない事前条件• よいテストを書くとプログラミングが 加速する
  • 自己テストコードの意義• プログラマの大半が実際にコードを書 いている時間は短い• 多くの時間をデバッグに費やしている
  • テストの自動化• テストを完全に自動化して、その結果 もテストにチェックさせる• テストを頻繁に実行しておくと、バグ 検出に絶大な力を発揮する• バグの発見にかかる時間が削減
  • 機能追加はテストから書く• 機能を追加するためになすべきことを 自問することになる• 実装よりもインターフェースに集中する ことになる• コーディングの完了時点が明確になる →テストがうまくいったとき
  • JUnitテストフレームワーク
  • テストクラスの作成• テストを内包するクラスは、TestCaseク ラスを継承しなければならない• TestSuiteクラスにひとまとめにして入れ ておくことができる
  • テスト対象(test fixture)の準備• テスト対象を操作するメソッド • setUp • tearDown
  • 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(); } }
  • テストを書く• assert(表明)メソッド • 真なら正常、そうでなければエラー を通知
  • class FileReaderTester . . . protected void testRead() throw IOException { char ch = ‘&’; for (int i = 0; i < 4; i++) ch = (char) _input.read(); assert(‘d’ == ch); }
  • テストを実行• テストスイートの作成 • テストケースを指定• TestRunnerで実行
  • 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()); }
  • 【実行結果】.Time: 0.110OK (1 tests)
  • class FileReaderTester . . . protected void testRead() throw IOException { char ch = ‘&’; for (int i = 0; i < 4; i++) ch = (char) _input.read(); assert(‘2’ == ch); //故意のエラー }
  • 【実行結果】.FTime: 0.170!!!FAILURES!!!Test Results:Run: 1Failures: 1Erors: 0There was 1failure:1) FileReaderTester.testReadtest.framework.AssertionFailedError
  • • テストを書く際は、初めは失敗するよ うにしておく• 本当にテストが実行され、期待どお りにテストしているかを確認するため
  • 単体テストと機能テスト• 単体テスト:プログラマの生産性を向上する ため• 機能テスト:ソフトウェア全体の動作を保証 するため
  • バグを発見したら• まずはバグを明らかにするための単体テスト を書くべき • バグを突き止めるのにも、再度おなじバグ が単体テストをすり抜けないことを保証す るのにも役立つ
  • テストの追加• 一番怪しいと思う部分をテストする• 失敗の恐れのある境界条件を考えて、 そこを集中的にテスト• 予想されるエラーが正しく起こること の確認を忘れない
  • やめ時はいつか• 過剰なテスト • やる気が失せて、何も書けずに終わる危険• リスクがどこにあるか注目すべき • コードを見て、複雑になってくるところ • 機能をみて、エラーが起こりそうなところ