JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
•Download as KEY, PDF•
30 likes•7,122 views
オープンソースカンファレンス2012北海道 札幌Javaコミュニティでの講演資料
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
Similar to JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト (20)
More from Shuji Watanabe
More from Shuji Watanabe (20)
Recently uploaded
Recently uploaded (11)
JUnit実践入門 xUnitTestPatternsで学ぶユニットテスト
- 1. 実践JUnit xUnitTestPatternsから学ぶユニットテスト 2012.06.16 OSC 2012 北海道 Shuji Watanabe (@shuji_w6e) 1
- 2. 本日の内容
- 3. 本日の内容 ユニットテストの目的
- 4. 本日の内容 ユニットテストの目的 ユニットテストの実践
- 5. 本日の内容 ユニットテストの目的 ユニットテストの実践 ユニットテストの問題
- 6. SHUJI Watanabe Java デベロッパー 要件定義からテストまで全領域対応 Blog「やさしいデスマーチ」 札幌Javaコミュニティ Java, Groovy, JavaFX, MongoDB TDD, ユースケース駆動開発, テスト
- 7. WEB+DB PRESS vol.69 JUnit実践入門 カスタムMatcher パラメータ化テスト テストの構造化 カスタムRule Cucumebr-junit
- 8. XUnit Test Patterns http://xunitpatterns.com/ Webで読めます（英語）
- 9. ユニットテストの目的
- 10. テストが 必要なワケ http://www.flickr.com/photos/essecento/4297955162/
- 11. スキル不足 仕様変更 経験不足 複雑な要件 不安 http://www.flickr.com/photos/yopse/3772030400/
- 12. 不完全な人間 http://www.flickr.com/photos/sharynmorrow/3948100/
- 14. テストの４象限モデル ビジネス面 手動 機能テスト 受け入れテスト 製品を批評 チームを支援 ストーリーテスト ユーザビリティテスト 負荷テスト ユニットテスト パフォーマンステスト 自動 技術面
- 15. テストの４象限モデル ビジネス面 手動 機能テスト 受け入れテスト 製品を批評 チームを支援 ストーリーテスト ユーザビリティテスト 負荷テスト ユニットテスト パフォーマンステスト 自動 技術面
- 16. テストの４象限モデル ビジネス面 手動 機能テスト 受け入れテスト 製品を批評 チームを支援 ストーリーテスト ユーザビリティテスト 負荷テスト ユニットテスト パフォーマンステスト 自動 技術面
- 20. セーフティネット http://www.flickr.com/photos/32010000@N08/2987901256/
- 23. ユニットテストの実践
- 24. テストケースとは？ テスト対象（sut: System Under Test）に 特定の操作を行い、 実測値（Actual Value）が 期待値（Expected Value）となることを 検証（Verify）する
- 27. 4フェイズ テスト 初期化処理（SetUp） 実行（Exercise） @Test public void test() { 検証（Verify） // SetUp // Exercise 後処理（TearDown） // Verify // TearDown }
- 28. アサーション アサーションとは「こうなる」という表明 assertThat(actual, is(expected)); static importされたメソッド 自然言語風の記述 assert that actual is expected 変数名（actual, expected）
- 29. Matcher API JUnit4の機能 一致する条件を定義したオブジェクト assertThat(actual, is(expected)); isはIsオブジェクトを返す Isはequalsを使った一致を行うMatcher 他にも多くのMatcherがある
- 31. ユニットテストと設計 ユニットテストはサンプルコード 自分が最初のユーザー（Eat your own dog food） APIが使いやすいかをテストする テストできないAPIは再設計する
- 32. 例）計算機クラス public class Calculator { // 割り算を行うメソッド public int divide(int x, int y) { return x / y; } }
- 33. 例）テストコード @Test public void test() { // SetUp Calculator sut = new Calculator(); float expected = 1.5; // Exercise float actual = sut.divide(6, 4); // Verify assertThat(actual, is(expected)); }
- 34. 例）APIの設計ミス public class Calculator { // 割り算を行うメソッド public float divide(float x, float y) { return x / y; } }
- 35. API設計とユニットテスト テストコードでAPI設計を検証出来る 期待値が検証出来ないAPI 使いにくい／解りにくいAPI テストコードを意識してAPIを設計する 突き詰めるとテスト駆動開発（TDD） テストを先に書く（テストファースト）
- 36. TDDのサイクル 1.設計する 5.リファクタリング Heuristics 2.テストを書く 4.テストを成功させる 3.コードを書く
- 38. ユニットテストの問題
- 39. 不安定なテスト テスト結果が不定 ランダム性やシステム時間に依存したテスト 環境に依存したテスト テスト結果が一定でないと信頼できない オオカミ少年問題 常にすべてのテストが成功することを維持
- 41. 増えるテストコード 重複 DRY原則(Don t Repeat Yourself） やり過ぎると可読性が落ちる テストはテストケースで独立すべき ネストしたクラスの利用（Enclosed） パラメータ化テスト
- 42. Enclosedテストクラス テストクラスの構造化 テストをコンテキスト（文脈）で整理 @RunWiht(Enclosed.class) public void ArrayListTest { public static class 初期状態のとき { @Test public void test() {} } public static class 要素が1つのとき { @Test public void test() {} } }
- 43. Enclosedテストクラス テストクラスの構造化 テストをコンテキスト（文脈）で整理 @RunWiht(Enclosed.class) public void ArrayListTest { public static class 初期状態のとき { @Test public void test() {} } public static class 要素が1つのとき { @Test public void test() {} } }
- 44. パラメータ化テスト テストデータとテストメソッドを分離 @RunWiht(Theories.class) public void CalculatorTest { @DataPoints public static Param[] PARAMS = { new Param(3, 4, 12), new Param(1, 5, 5), .... }; @Theory public void divideのテスト(Param p) { // } }
- 45. パラメータ化テスト テストデータとテストメソッドを分離 @RunWiht(Theories.class) public void CalculatorTest { @DataPoints public static Param[] PARAMS = { new Param(3, 4, 12), new Param(1, 5, 5), .... }; @Theory public void divideのテスト(Param p) { // } }
- 46. 詳しくはWEB+DB vol.69で JUnit実践入門 カスタムMatcher パラメータ化テスト テストの構造化 カスタムRule Cucumebr-junit
- 48. まとめ
- 51. おしまい
Editor's Notes
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n