約 1,163,222 件
https://w.atwiki.jp/hikotaro_wiki/pages/28.html
jUnitではユニットテストをテストクラスのテストメソッドとして定義します。 テストメソッドには、テスト対象となるクラスやメソッドの振る舞いを検証するテストコードを記述します。 テストメソッドは以下の制約で作成しなければなりません。 publicメソッドとする org.junit.Testアノテーションを付与する 戻り値をvoidとし、引数を持たない メソッド名は、理解しやすいように日本語のメソッド名を用います。 テストメソッドのひな型は以下のようになります。 package junit.tutorial; import static org.junit.Assert.*; import org.junit.Test; public class XXXXXTest { @Test public void テスト名() throws Exception { // テスト対象となるクラスやメソッドの振る舞いの検証 } } テストメソッドのthrows句 テストメソッドを簡単に挿入する jUnitへ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/2.html
開発技法 Java 読書リスト プラグイン紹介 メニュー メニュー2 リンク @wiki @wikiご利用ガイド ここを編集
https://w.atwiki.jp/hikotaro_wiki/pages/17.html
新規Javaプロジェクトの作成 パッケージエクスプローラで右クリックしてコンテキストメニューを表示し、[新規]-[Javaプロジェクト]を選択します。 「新規プロジェクト」ダイアログが表示されるので、[プロジェクト名]に任意の名前を入力し、[完了]をクリックしてください。 ライブラリの追加 jUnitのJARファイルをプロジェクトのライブラリに追加します。 公式サイトからJARファイル(junit-x.jar、hamcrest-core-x.jar)をダウンロードし、プロジェクトフォルダにコピーしてください。 続けてコピーしたJARファイルを右クリックしてコンテキストメニューを表示し、[ビルド・パス]-[ビルド・パスに追加]を選択します。 テスト対象クラスを作成する プロジェクトのソースフォルダ(srcフォルダ)を右クリックし、コンテキストメニューから[新規]-[クラス]を選択します。 「新規Javaクラス」ダイアログが表示されるので、[パッケージ]と[名前]に任意の名前を入力し、[完了]をクリックします。 package junit.tutorial; public class Calculator { public int multiply(int x, int y) { return x * y; } public int divide(int x, int y) { return x / y; } } テストクラスを作成する testソースフォルダの作成 テストクラスは、一般的にテスト対象クラスとは異なるソースフォルダ(*1)を作成します。 これは、ソフトウェアとしてリリースするプロダクションコードとリリース対象とならないテストコードを明確に分けたほうが都合が良いからです。 EclipseのJavaプロジェクトでは、デフォルトのソースフォルダは「src」のみなので、まずはテストコード用のソースフォルダ「test」を作成します。 ソースフォルダを追加するには、プロジェクトのコンテキストメニューから[ビルド・パス]-[新規ソース・フォルダ]を選択します。 「新規ソース・フォルダ」ダイアログが表示されたら、[フォルダ名]に「test」と入力して[完了]をクリックします。 (*1)ソースフォルダはプロジェクト階層における最上位フォルダーです。ソースフォルダは、.java ファイルを格納しているパッケージのルートです。 コンパイラーは、ソースフォルダに含まれているファイルを出力フォルダーに書き込むために .class ファイルに変換します。 テストクラスの作成 ソースフォルダ「test」のコンテキストメニューを開き、[新規]-[jUnitテスト・ケース]を選択します。 「新規jUnitテスト・ケース」ダイアログが表示されるので、[名前]に任意の名前、[テスト元クラス]に、テスト対象クラスの名前を入力し、[完了]をクリックしてください。 package junit.tutorial; import static org.junit.Assert.*; import org.junit.Test; public class CalculatorTest { @Test public void test() { fail("Not yet implemented"); } } テストを実行する テストクラスのコンテキストメニューを開き、[実行]-[jUnitテスト]を選択します。 jUnitへ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/24.html
ユニットテストは、クラスやメソッドを対象としたプログラムを検証するためのテストであり、ソフトウェアの中では最も小さい粒度のテストです。 ユニットテストでは、対象のクラスやメソッドが期待された振る舞いをするかを検証し、テストが成功することによってそれを保証します。 この「期待された振る舞い」とは、言い換えれば、対象のクラスやメソッドの仕様です。 ユニットテストの特徴 ユニットテストはプログラムとして実行できる仕様書となることが特徴です。そして、ユニットテストが成功する限り、正確な仕様書となります。 クラスやメソッドの仕様を自然言語(日本語や英語)で記述してテストを行うことは不可能ではありません。しかしながら、自然言語ではあいまいさを完全に排除することは難しく、句読点やニュアンスで読み手が誤解するかもしれません。 一方、クラスやメソッドの仕様をプログラムとして記述するならば、あいまいさが含まれることなく明確に記述できます。 【乗算メソッドのドキュメント】 public class Calculator { /** * 引数で与えられた2つの値を掛け合わせた値を返す * @param x 1つ目の引数 * @param y 2つ目の引数 * @return xとyを掛け合わせた値 */ public int multiply(int x, int y) { return x * y; } } jUnitによるユニットテストでは対象のクラスやメソッドの仕様を実行できる形式で記述できます。 また、このとき作成したコードは対象のクラスやメソッドの実行できるサンプルコードと考えることもできます。 そして、プログラマ自身が、作成したクラスやメソッドの最小のユーザです。もし、テストコードを書いているときに使いにくいと感じたならば、設計や仕様に問題があることに気づくこともできます。 また、プログラムとしてユニットテストを行う場合、最初にテストコードを記述するコストはかかりますが、実行するコストはほとんど必要ありません。したがって、何度でも繰り返し実行できますし、それを頻繁に行うことも可能です。 【乗算メソッドのテストコード】 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)); } } テストへ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/16.html
Gradleプラグインのインストール 1. Eclipseメニューの[ヘルプ] - [Eclipseマーケットプレース]を選択します。 2. 「Eclipseマーケット」画面で、検索に「Buildship」と入力し、右上の「実行ボタン」をクリックします。 3. 一覧に「Buildship Gradle Integration」が表示されますので、「インストール」ボタンをクリックします。 4. 「選択されたフィーチャーの確認」画面が表示されます。「Buildship Gradle Integration」がチェックされていることを確認し、「確認」ボタンをクリックします。 5. 「ライセンスのレビュー」画面が表示されますので、「使用条件の条項に同意します」をクリックして、「完了」ボタンをクリックします。 6. インストールが完了すると、再起動を促すダイアログが表示されますので「はい」をクリックしてEclipseを再起動します。 Gradleプロジェクトを作成する 1. Eclipseメニューから[ファイル] - [新規] - [プロジェクト]を選択します。 2. 「新規プロジェクト」画面が表示されます。一覧の「Gradle」をクリックし、その下層にある「Gradleプロジェクト」をクリックした後、「次へ」ボタンをクリックします。 3. 「新規Gradleプロジェクト」画面が表示されます。「プロジェクト名」に任意の文字列を入力し、「次へ」ボタンをクリックします。 4. 「Gradleプロジェクトのプレビュー」画面が表示されます。「完了」ボタンをクリックします。 eclipseへ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/10.html
コメントプラグイン @wikiのwikiモードでは #comment() と入力することでコメントフォームを簡単に作成することができます。 詳しくはこちらをご覧ください。 ＝＞http //www1.atwiki.jp/guide/pages/921.html#id_476878da たとえば、#comment() と入力すると以下のように表示されます。 名前 コメント
https://w.atwiki.jp/hikotaro_wiki/pages/27.html
jUnitテストを始めよう テストコードの記述 jUnitへ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/19.html
Javaの世界では標準APIはもちろん、ほどんどのライヴラリでは英語表記のメソッド名とクラス名が使用されています。また、一般的に、Javaの多くのコーディング標準では、「メソッド名には半角英数でわかりやすい英単語を使用すること」となっています。 しかし、テストコードは別です。英語で格好よくテストの内容を記述でき、それを読み取ることができるのであれば、英語を使うことが望ましいのですが、日本語でソフトウェアを開発するならば、日本語でテストの内容を把握できるメリットのほうが大きくなります。 メソッドの一覧はjavadocに出力することでテスト項目の一覧となりますし、テストクラスのアウトラインを参照すればそのテストクラスで行っているテストが簡単に把握できます。テストが失敗したときのレポートも、失敗したテストメソッドが日本語で出力されていることにより理解しやすくなります。 テストコードの記述へ戻る トップページへ戻る
https://w.atwiki.jp/hikotaro_wiki/pages/25.html
自動化されたテスト - 繰り返しいつでも実行できること ユニットテストに限らず、ソフトウェアテストは可能な限り自動化するべきです。 つまり、テストがプログラムとして繰り返し何度でも実行できる状態にします。 その結果、不具合などを早い段階でフィードバックでき、安心してリファクタリングや機能拡張を行うことができるようになります。 不安定なテスト - 結果が一定でないテストを避けること ユニットテストでは、常にすべてのテストが成功している状態を維持することが望ましいです。 成功しないテストを放置する状態や実行ごとに成功するか失敗するかわからないテスト(不完全なテスト 例えば、現在時刻に依存するテストなど)がある状態は望ましくありません。 ドキュメントとしてのテスト - 仕様書として読めること テストケースは、テスト対象のクラスやメソッドに対し開発者が想定しているさまざまなユースケースを記述したものです。また、テストが成功する限り、テストケースで定義されている動きは保証されています。したがって、テストケースは最も正確なドキュメントであり、テスト対象のサンプルコードです。 テストコードもプロダクションコードと同じようにメンテナンスし続ける必要があります。 常にテストコードを読む人を意識してテストコードを書くように心がけましょう。 問題の局所化 - テスト失敗時に問題を特定しやすいこと テストケースは、十分に小さい単位で可能な限り多く作るべきです。 テストが十分に小さいならば、何らかの原因でテストが失敗したとしても、影響範囲と条件が絞りやすくなります。 不明瞭なテスト - 可読性の低いテストコードは避けること テストケースにおいて、前提条件、実行、検証などが複雑に入り組んでいると、テストコードは非常に読みにくくなります。読みにくいコードはメンテナンス性も悪く、テストの質にも大きく影響を与えます。したがって、テストコードは可能な限りシンプルに分かりやすく記述するべきです。特に、各ステートメント(行)が、前提条件、実行、検証のどこに属しているかが明確な短いコードであるべきです。 前提条件は、同じコードが2回以上現れたならばsetUpメソッドに抽出します。同じテストクラスの中で2つ以上の前提条件が出現したならば、コンテキストごとのテストを検討してください。 テストのための「実行」は1つのテストケースで1だけ行うようにしてください。ある操作をして、別の操作をして、また別の操作をする、といったテストの実行フェーズを行うと、何が原因でテストが失敗したかがわかりにくくなります。このような場合は、前提となる前提条件を含め、テストする実行は1つの操作としてください。 検証も、1つのテストケースで1つだけ行うのが理想です。 独立したテスト - 実行順序に依存しないこと テストケースは、可能な限りお互いに影響を与えないように定義すべきです。あるテストの結果やテストの実行順番がテストの結果に影響を与えるならば、テストケースの追加や削除により予期しない形でテストが失敗することになります。 テストを行いにくい設計を避けることも重要です。ハードコーディングされた設定ファイルを読み込むリソースやミュータブルなオブジェクトをシングルトンとして設計すると、この罠にはまりやすくなります。 テストへ戻る トップページへ戻る 参考 xUnit Test Patterns
https://w.atwiki.jp/hikotaro_wiki/pages/9.html
@wikiにはいくつかの便利なプラグインがあります。 RSS アーカイブ インスタグラム コメント ニュース 動画(Youtube) 編集履歴 これ以外のプラグインについては@wikiガイドをご覧ください = http //atwiki.jp/guide/