http://w.atwiki.jp/hikotaro_wiki/ ひこたろう @ ウィキ ja 2016-01-22T07:33:16+09:00 1453415596 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/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/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/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 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]]によるユニットテストでは対象のクラスやメソッドの仕様を実行できる形式で記述できます。 また、このとき作成したコードは対象のクラスやメソッドの実行できるサンプルコードと考えることもできます。 そして、プログラマ自身が、作成したクラスやメソッドの最小のユーザです。もし、テストコードを書いているときに使いにくいと感じたならば、設計や仕様に問題があることに気づくこともできます。 また、プログラムとしてユニットテストを行う場合、最初にテストコードを記述するコストはかかりますが、実行するコストはほとんど必要ありません。したがって、何度でも繰り返し実行できますし、それを頻繁に行うことも可能です。 【乗算メソッドのテスト 2016-01-21T07:55:43+09:00 1453330543 https://w.atwiki.jp/hikotaro_wiki/pages/23.html ---- **[[ソフトウェアテストとは]] **[[テスト技法]] **[[ユニットテストとは]] **[[ユニットテストのパターン]] ---- [[開発技法]]へ戻る [[トップページ]]へ戻る 2016-01-21T07:28:22+09:00 1453328902 https://w.atwiki.jp/hikotaro_wiki/pages/22.html ---- **ホワイトボックステストとブラックボックステスト &bold(){ホワイトボックステスト}は内部のロジックや仕様について考慮してテストケースを設計します。 データの抽出時に内部ロジックの分岐などを考慮し、[[テスト]]が可能な限りすべてのロジックを実行するデータを作成します。 &bold(){ブラックボックステスト}とは、文字どおりソフトウェアの内部仕様について考慮せず、外部仕様のみからテストケースを設計します。 ブラックボックステストは、ユーザ受入テストや機能テストなど、比較的に大きな粒度でソフトウェアをエンドトゥエンドで検証するテストで採用されます。 **同値クラスに対するテスト &bold(){同値クラスに対するテスト}は、ソフトウェアが同様に結果をもたらす値を&bold(){同値クラス}としてグループ化し、各同値クラスからテストデータを選択するテスト技法です。 同値クラスに対するテストは、ブラックボックステストに分類されます。 **境界値に対するテスト 境界値に対するテストは、ソフトウェアが異なる結果をもたらす値(境界値)に着目し、境界値の近傍からテストデータを選択する技法です。 ---- [[テスト]]へ戻る [[トップページ]]へ戻る 2016-01-21T07:28:47+09:00 1453328927 https://w.atwiki.jp/hikotaro_wiki/pages/21.html ---- **ソフトウェアの特徴 ソフトウェア開発による[[テスト]]の定義は「ある条件下においてソフトウェアの振る舞いを記録し、その結果が期待される結果となることを検証するプロセス」です。 1つ目のポイントは、テストに「ある条件下」という制約があることです。 これは「前提条件」や「事前条件」と呼ばれ、テストに使用するデータ、環境、事前の操作手順などが含まれます。 前提条件が異なれば検証する内容も異なるため、テストでは前提条件が明確になっていなければなりません。 2つ目のポイントは、何らかの方法で「ソフトウェアの振る舞いを記録する」ことです。 記録できなければ、期待される結果となることを検証できません。 たとえば、出力されるデータやデータベースなどが、どのような状態であるかを確認できなければなりません。 最後のポイントは、「期待される結果との検証」を行うことです。 つまりランダム性の高い振る舞いであればあるほど、テストは難しくなります。 ソフトウェア開発の大きな特徴として、プログラム上の問題や制約などが実際に作ってみなければわからないことが多いこと、そして一度作ったプログラムを破棄して作りなおすことが比較的に簡単であることが挙げられます。 このため、製造業や建築業で行われているような設計業務で徹底的に検証して品質を高める手法は、ソフトウェア開発ではあまり効果的ではありません。 ソフトウェア開発では、作りながら同時にテストを行ったり、実施したテストから得られたフィードバックからテストを追加したりする方法が有効です。 **テストケースとテストスイート ソフトウェアテストでは、1つのテスト項目を&bold(){テストケース}と呼びます。 テストケースには、テストの前提条件、実行する操作、期待される値や状態がすべて含まれます。つまり、「どのような条件でどのような操作をしたならば、こうなることが期待される」を記述したものがテストケースです。 通常、ソフトウェアテストは複数のテストケースで構成されています。テストケースの数が増えてくれば、何らかの形で似たテストケースをまとめる必要があります。このように、いくつかのテストケースをまとめたものを&bold(){テストスイート}と呼びます。 **ソフトウェアテストの目的 ソ 2016-01-21T07:28:32+09:00 1453328912 https://w.atwiki.jp/hikotaro_wiki/pages/20.html ---- **[[テスト]] ---- [[トップページ]]へ戻る 2016-01-21T23:04:49+09:00 1453385089