http://w.atwiki.jp/hikotaro_wiki/ ひこたろう @ ウィキ ja 2016-01-22T07:40:47+09:00 1453416047 https://w.atwiki.jp/hikotaro_wiki/pages/12.html ---- -統合開発環境 --[[eclipse]] -テスト --[[jUnit]] --[[QuickJUnit]] -Webフーレムワーク --[[SpringBoot]] ---- [[トップページ]]へ戻る 2016-01-22T07:40:47+09:00 1453416047 https://w.atwiki.jp/hikotaro_wiki/pages/30.html ---- Eclipseのテンプレート機能を使えば、[[テスト]]メソッドのひな型をテストクラスの中に挿入することができます。 *** ***使い方 テストクラスの中のテストを書きたい場所で「test」と入力してショートカットctrl + spaceを押します。 ---- [[jUnitによるユニットテストの記法]]へ戻る [[トップページ]]へ戻る 2016-01-22T07:33:16+09:00 1453415596 https://w.atwiki.jp/hikotaro_wiki/pages/28.html ---- [[jUnit]]ではユニットテストをテストクラスのテストメソッドとして定義します。 [[テスト]]メソッドには、テスト対象となるクラスやメソッドの振る舞いを検証するテストコードを記述します。 テストメソッドは以下の制約で作成しなければなりません。 -publicメソッドとする -org.junit.Testアノテーションを付与する -戻り値をvoidとし、引数を持たない メソッド名は、理解しやすいように日本語のメソッド名を用います。 テストメソッドのひな型は以下のようになります。 #highlight(java){{ package junit.tutorial; import static org.junit.Assert.*; import org.junit.Test; public class XXXXXTest { @Test public void テスト名() throws Exception { // テスト対象となるクラスやメソッドの振る舞いの検証 } } }} ***[[テストメソッドのthrows句]] ***[[テストメソッドを簡単に挿入する]] ---- [[jUnit]]へ戻る [[トップページ]]へ戻る 2016-01-22T07:24:21+09:00 1453415061 https://w.atwiki.jp/hikotaro_wiki/pages/29.html ---- [[jUnit]]では[[テスト]]メソッドが例外を送出したときにテスト失敗として扱うため、通常はthrows句にExceptionクラスを指定します。 一般的な[[Java]]のコーディング標準では、メソッドのthrows句にThrowableやExceptionなどの基底となる例外クラスを指定することを禁止しています。 これは、例外処理を適切に行うために重要なルールであり、レビューや静的コード解析ツールなどでチェックするされる項目となっています。 しかしながら、jUnitでユニットテストを書く場合は状況が異なります。 テストメソッドはjUnitによって実行されるメソッドであり、例外処理はフレームワーク上で行われます。 テストメソッドから期待されていない状態で例外が送出された場合、そのテストは失敗とし、エラーメッセージが表示されるしくみです。 したがって、throws句に送出される可能性がある例外を詳細に列挙したかどうかは、テストの挙動に影響を与えません。 また、テストメソッド内ではさまざまなクラスが利用されます。 テストコードを書いたあとにAPIの仕様を変更し、新しいタイプの例外が送出されるかもしれません。 そのたびにテストメソッドのthrows句を修正するのは非常に面倒です。 これらの理由から、コーディング基準に含まれる「throws Exceptionの禁止」はテストコードに適用すべきではありません。 ---- [[jUnitによるユニットテストの記法]]へ戻る [[トップページ]]へ戻る 2016-01-22T07:23:00+09:00 1453414980 https://w.atwiki.jp/hikotaro_wiki/pages/13.html ---- jUnitは、Kent BeckやErich Gammaによって開発された[[Java]]のテスティングフレームワークです。 「どのように[[テスト]]を記述して、実行し、検証するか」についてサポートします。 主に次のような機能を持ちます。 -テストの実行フレームワーク -テストの期待値と実測値の検証API -テストケースのフォーマット ***[[jUnitチュートリアル]] ***[[jUnitによるユニットテストの記法]] #amazon(477415377X,image,text) ---- [[Java]]へ戻る [[トップページ]]へ戻る 2016-01-22T07:06:54+09:00 1453414014 https://w.atwiki.jp/hikotaro_wiki/pages/2.html ---- -[[開発技法]] -[[Java]] -[[読書リスト]] ---- -[[プラグイン紹介>プラグイン]] -[[メニュー]] -[[メニュー2]] ---- **リンク -[[@wiki>>http://atwiki.jp]] -[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] // リンクを張るには "[" 2つで文字列を括ります。 // ">" の左側に文字、右側にURLを記述するとリンクになります //**更新履歴 //#recent(20) &link_editmenu(text=ここを編集) 2016-01-22T07:06:36+09:00 1453413996 https://w.atwiki.jp/hikotaro_wiki/pages/20.html ---- **[[テスト]] ---- [[トップページ]]へ戻る 2016-01-21T23:04:49+09:00 1453385089 https://w.atwiki.jp/hikotaro_wiki/pages/27.html ---- ***[[jUnitテストを始めよう]] ***[[テストコードの記述]] ---- [[jUnit]]へ戻る [[トップページ]]へ戻る 2016-01-21T23:00:52+09:00 1453384852 https://w.atwiki.jp/hikotaro_wiki/pages/25.html ---- **自動化されたテスト - 繰り返しいつでも実行できること ユニットテストに限らず、ソフトウェアテストは可能な限り自動化するべきです。 つまり、[[テスト]]がプログラムとして繰り返し何度でも実行できる状態にします。 その結果、不具合などを早い段階でフィードバックでき、安心してリファクタリングや機能拡張を行うことができるようになります。 **不安定なテスト - 結果が一定でないテストを避けること ユニットテストでは、常にすべてのテストが成功している状態を維持することが望ましいです。 成功しないテストを放置する状態や実行ごとに成功するか失敗するかわからないテスト(不完全なテスト:例えば、現在時刻に依存するテストなど)がある状態は望ましくありません。 **ドキュメントとしてのテスト - 仕様書として読めること テストケースは、テスト対象のクラスやメソッドに対し開発者が想定しているさまざまなユースケースを記述したものです。また、テストが成功する限り、テストケースで定義されている動きは保証されています。したがって、テストケースは最も正確なドキュメントであり、テスト対象のサンプルコードです。 テストコードもプロダクションコードと同じようにメンテナンスし続ける必要があります。 &u(){常にテストコードを読む人を意識してテストコードを書くように心がけましょう。} **問題の局所化 - テスト失敗時に問題を特定しやすいこと テストケースは、十分に小さい単位で可能な限り多く作るべきです。 テストが十分に小さいならば、何らかの原因でテストが失敗したとしても、影響範囲と条件が絞りやすくなります。 ** 不明瞭なテスト - 可読性の低いテストコードは避けること テストケースにおいて、前提条件、実行、検証などが複雑に入り組んでいると、テストコードは非常に読みにくくなります。読みにくいコードはメンテナンス性も悪く、テストの質にも大きく影響を与えます。したがって、テストコードは可能な限りシンプルに分かりやすく記述するべきです。特に、各ステートメント(行)が、前提条件、実行、検証のどこに属しているかが明確な短いコードであるべきです。 前提条件は、同じコードが2回以上現れたならばsetUpメソッドに抽出します。同じテストクラスの中で2つ以上の前提条件が出現したならば、コンテキストごとのテストを検討してください。 テストのための「実行」は1つのテストケースで1だけ行うようにしてください。ある操作をして、別の操作をして、また別の操作をする、といったテストの実行フェーズを行うと、何が原因でテストが失敗したかがわかりにくくなります。このような場合は、前提となる前提条件を含め、テストする実行は1つの操作としてください。 検証も、1つのテストケースで1つだけ行うのが理想です。 ** 独立したテスト - 実行順序に依存しないこと テストケースは、可能な限りお互いに影響を与えないように定義すべきです。あるテストの結果やテストの実行順番がテストの結果に影響を与えるならば、テストケースの追加や削除により予期しない形でテストが失敗することになります。 テストを行いにくい設計を避けることも重要です。ハードコーディングされた設定ファイルを読み込むリソースやミュータブルなオブジェクトをシングルトンとして設計すると、この罠にはまりやすくなります。 ---- [[テスト]]へ戻る [[トップページ]]へ戻る 参考: xUnit Test Patterns 2016-01-21T08:17:53+09:00 1453331873 https://w.atwiki.jp/hikotaro_wiki/pages/24.html ---- ユニットテストは、クラスやメソッドを対象としたプログラムを検証するためのテストであり、ソフトウェアの中では最も小さい粒度のテストです。 ユニットテストでは、対象のクラスやメソッドが期待された振る舞いをするかを検証し、テストが成功することによってそれを保証します。 この「期待された振る舞い」とは、言い換えれば、対象のクラスやメソッドの仕様です。 **ユニットテストの特徴 ユニットテストはプログラムとして実行できる仕様書となることが特徴です。そして、ユニットテストが成功する限り、正確な仕様書となります。 クラスやメソッドの仕様を自然言語(日本語や英語)で記述して[[テスト]]を行うことは不可能ではありません。しかしながら、自然言語ではあいまいさを完全に排除することは難しく、句読点やニュアンスで読み手が誤解するかもしれません。 一方、クラスやメソッドの仕様をプログラムとして記述するならば、あいまいさが含まれることなく明確に記述できます。 【乗算メソッドのドキュメント】 #highlight(java){{ public class Calculator { /** * 引数で与えられた2つの値を掛け合わせた値を返す * @param x 1つ目の引数 * @param y 2つ目の引数 * @return xとyを掛け合わせた値 */ public int multiply(int x, int y) { return x * y; } } }} [[jUnit]]によるユニットテストでは対象のクラスやメソッドの仕様を実行できる形式で記述できます。 また、このとき作成したコードは対象のクラスやメソッドの実行できるサンプルコードと考えることもできます。 そして、プログラマ自身が、作成したクラスやメソッドの最小のユーザです。もし、テストコードを書いているときに使いにくいと感じたならば、設計や仕様に問題があることに気づくこともできます。 また、プログラムとしてユニットテストを行う場合、最初にテストコードを記述するコストはかかりますが、実行するコストはほとんど必要ありません。したがって、何度でも繰り返し実行できますし、それを頻繁に行うことも可能です。 【乗算メソッドのテストコード】 #highlight(java){{ public class CalculatorTest { @Test public void multiplyで3と4の乗算結果が取得できる() { Calculator calc = new Calculator(); int expected = 12; int actual = calc.multiply(3, 4); assertThat(actual, is(expected)); } @Test public void multiplyで5と7の乗算結果が取得できる() { Calculator calc = new Calculator(); int expected = 35; int actual = calc.multiply(5, 7); assertThat(actual, is(expected)); } } }} ---- [[テスト]]へ戻る [[トップページ]]へ戻る 2016-01-21T07:55:43+09:00 1453330543