Download as PDF, PPTX
![[AWS初心者向けWebinar] 利用者が実施するAWS上でのセキュリティ対策](https://cdn.slidesharecdn.com/ss_thumbnails/20151217-aws-security-151218023451-thumbnail.jpg?width=640&height=640&fit=bounds)
![[PGConf.ASIA 2018]Deep Dive on Amazon Aurora with PostgreSQL Compatibility](https://cdn.slidesharecdn.com/ss_thumbnails/20181212pgconfasiaaurorapostgresql-181212055637-thumbnail.jpg?width=640&height=640&fit=bounds)
![JUnit入門/TDD入門[新人研修資料]](https://cdn.slidesharecdn.com/ss_thumbnails/unittesttdd-210702050313-thumbnail.jpg?width=640&height=640&fit=bounds)
第1回JUnit勉強会ハンズオン
- 1.
- 2. 勉強会開始！ でもその前に・・・ 勉強会のゴール 受講者個々人が単体テストの重要性を理解し、 業務システムに適用可能な単体テストスキルを身につけることをゴールとします。 今後の計画 第1回 ∼基本編∼ JUnitに今後触れて行くに当たっての基本 第2回∼テストダブル（モック）編∼ JMockitを利用したモックテクニックをハンズオン 第3回 ∼DB編∼ DBUnitを利用したDB周りのテスト実施をハンズオン 第4回 ∼応用編∼ CIとの連携やDIコンテナ環境での単体テスト 利用するJUnitのバージョン 4.11を利用する前提とします。
- 3. 目次∼基本編∼ ① テストクラスの定義方法 ② テストメソッドの作成と命名ルール （こう書くと分かりやすい） ③単純なテストクラスの作成 （モダンなAssertion方法を学ぶ） ④ Exceptionの発生をテストする ⑤ 構造化テスト(@Enclosed)を活用しよう！ ⑥ 主要なJUnit関連アノテーションと使いどころ
- 4.
- 5.
- 6.
- 7.
- 8. ハンズオン1 - テストクラスとメソッドの定義 これまでの説明を元に「Nabeatu」クラスにテストメソッドを定義してみましょう。 ・テスト対象メソッドは「aho」 （引数が3の倍数、または3 が含まれる場合は AHO になります） ・3を渡した時に AHO が返ります ・4を渡した時は4がそのまま返ります ※ 一旦メソッドの定義だけ行ってください。中の実装はこの後解説します。
- 9. フェーズ 内容 どこに書くか？ 事前準備(setup) テスト対象オブジェクト(SUT ※)の初期化 ※ System Under Testの略 テストメソッド内、@Before、 @BeforeClass 実行（exercise) テスト対象操作の実行（1度だけ実行） テストメソッド内 検証 (verify) テスト結果の実測値が期待値と等価か検証 テストメソッド内 後処理 (tear down) 次のテスト実行に影響が無いよう後処理する テストメソッド内、@After @AfterClass 単体テストは基本的に次の4フェーズで構成されます。 可読性向上のためにどのフェーズを実行しているかコメントを残しましょう！ 4フェーズテストについて
- 10. JUnit4（正確には4.4以降）では、テスト結果は、org.junit.AssertクラスのassertThat メソッドとMatcherと呼ばれる仕組みを利用して検証します。 ③ Assertionの実施方法 Assert.assertThat(T actual,Matcher<? super T> matcher) actual テストの実測値（actual）を指定します。特に型を気にする必要はありません。 matcher actualとの比較方法と期待値を保持するオブジェクトです。 主にorg.hamcrest.CoreMatchersクラスのメソッドを利用して作成します。 ＜例＞ assertThat( hoge , is( hoge )); ・・・実測値と期待値をequalsで比較検証 assertThat(null, is(nullValue()); ・・・実測値がnullであることを検証
- 11. なぜMatcherを利用するのか？ ・より自然言語（英語）に近い形で記述できる 【JUnit3】 assertEqual (expected,actual) 【JUnit4∼】 assertThat (actual, is(expected)) JUnit4の方が「actual is expected」というような自然言語に近い読み方ができます。 ・オブジェクト検証のバリエーションが広がる Junit3までは検証方法は予めJUnit3側で用意されたメソッドの種類しか存在しませ んでした。（AssertEqual、AssertTure等） Matcherを自作（第四回ハンズオンで解説）することで、 必要に応じて検証方法を追加することができます。 これにより、複雑なテスト検証処理をMatcherに移すことができます。 Junit4でも従来のAssertion(assertEqualsやassertTureなど）も引き続き利用 可能な状態となっています。ただし、これら旧来の検証メソッドは下位互換性のため に残されているだけのようです。 原則として、今後はasserThatとMatcherの利用をお勧めします。
- 12. Matcherの種類と利用例 他にも沢山のMatcherが存在します。 参考サイト：http://qiita.com/opengl-8080/items/e57dab6e1fa5940850a3 ※リファレンスとしてとても有用 Matcher 何を検証するか 利用例（検証成功の例） is()等価(equals)である assertThat( hoge , is( hoge )); nullValue() nullである assertThat(null, is(nullValue()); startsWith() 指定した文字で始まる assertThat( hoge , is(startsWith( h )); endsWith() 指定した文字で終わる assertThat( fuga , is(endsWith( a )); greaterThan() 指定値よりも大きい assertThat(10, is(greaterThan(5)); lessThan() 指定値よりも小さい assertThat(5, is(lessThan(10)); not() 他matcher結果を反転(否定)する assertThat( hoge , is(not( fuga )); assertThat( hoge , is(not(nullValue()));
- 13.
- 14. @Testアノテーションの引数「expected」に発生する想定のテストクラスを指 定することでException発生を検証できます。 ※ try ~catchを書いた検証ロジック（JUnit3）は不要となりました。 ④ Exceptionの発生をテストする この例の場合、ArithmeticExceptionが発生した場合はテスト成功となり、 逆に発生しない場合はテスト失敗となります。 ※ 詳細なExceptionの検証（causeやmessageの取得/検証）は後述します。
- 15. JUnitはテストクラスのthrows句設定について特に制約はありません。 （定義してもいいですし、しなくても構いません） throws句をつけた場合、実際に例外が送出されると（@Testのexpected引数を 指定していない場合は）テストは失敗扱いとなります。 テストメソッドでのthrows句利用 対象メソッドの 検査例外の有無 throws句要否 補足 有 要 ※一律「throws Exception」 一律Exceptionを指定しておき、Exception発生を検証 するケースだけ、expected引数を利用すればOK。 無否 ＜テストメソッドでのthrows句の利用ポリシー＞ テスト対象メソッドが検査例外を発生させる場合は一律throws句を定義し、 Exception検証を行う場合にのみ＠Testのexpected引数を利用する。
- 16.
- 17.
- 18.
- 19.
- 20. ハンズオン4 - 構造化クラスの作成 Nabeatuクラスに以下の機能を追加しましょう。 【変更内容】 現在のahoメソッドは3の倍数と3を含む数値の場合にAHO を返しますが、任意の 数値を指定可能となるようクラスを修正してください。 どの数値を対象とするかはコンストラクタで指定可能としてください。 変更後のNabeatuプログラムを構造化クラスを使ってテストしてみましょう。
- 21. ⑥ 主要なJUnitアノテーションと使いどころ アノテーション 利用例や使いどころ @Test テストメソッドであることをJUnitに明示 @Test(expected=HogeException.class)… Exception発生を検証 @Test(timeout=1000) … 実行に1,000ms以上要した場合はテスト失敗扱い @Before 各テストメソッドの実行前に呼び出されるメソッドを指定 ・テストクラス(SUT)のインスタンス化 (SUTはテストクラスのフィールドとして保持） ・DBの初期化（第三回ハンズオンで解説） など @After 各テストメソッドの実行後に呼び出されるメソッドを指定 （DB関連の後処理等で利用。@Beforeと比べると利用頻度は低い） @Ignore 無視するテストケースに指定。 テストメソッドだけ定義して、後から実装を作る、といった場合に有効。 @Rule 従来のテストでは実現できない様々な振る舞いをテストに対して追加する仕組み ExpectedExceptionルールを利用する事で、@Test(expected)では不足していたExceptionの検証 (MessageやCauseの検証）を実施できる。
- 22. ハンズオン5 - 様々なバリエーションのテスト 以下のケースのテストメソッドを作成してみましょう。 ※出典：書籍「JUnit実践入門」（一部） ① 副作用を持つメソッドのテスト Counterクラスのincrementメソッドは呼び出す毎に1ずつ加算された値を返し ます。このメソッドのテストクラスを作成してみましょう。 なお、初回のincrementメソッド呼び出し時は 1 を返します。 ② 複合条件／テストしやすいメソッド設計を要するテスト FizzBuzzを実行するクラスを作成し、単体テストを作成してみましょう。 引数として整数を渡し、０∼引数までのFizzBuzz結果をそれぞれ標準出力 （System.out）したいです。 どのようなメソッドの設計とすると単体テストしやすいでしょうか？
- 23.
- 24. JUnitでよくある質問と回答 • 複数のテストケース（Assert）を1メソッドにまとめても良いか？ テスト成功／失敗した際に、 何が起こったのか切り分けられる粒度とすることが大切で す。 例えば、前出の「Nabeatu#aho」のテストを考えた時に、入力値1,2,3の検証を1つのメ ソッドで実行したとしましょう。このメソッドが失敗した場合 ・本来 AHO となるところが数値だったのか ・本来数値となるところが AHO だったのか ぱっと見で切り分けできません。 テストコードの可読性を上げるためにも、成功／失敗時に 何が起こったのか を推測でき るメソッドの切り分けにしましょう。
- 25.
- 26.