20

そのため、Guava には、メソッドの引数をチェックするためのシンプルでありながら便利な前提条件があります。しかし、「事後条件」クラスもあるのが妥当だと思います。それとも、Java がアサーションを提供しているからですか?

このようなクラスは存在しないため、数学が戻る前に後置条件をチェックするための「最良の」(実践的な) 代替方法は何ですか?

4

3 に答える 3

16

投稿条件をテストすることは不要です。Java で事後条件をテストする方法は、単体テストです。

単体テストでは、特定の入力に対して予測可能な出力が得られることを確認します。を使用Preconditionsすると、有効な入力があることを確認できるため、出力はテストによって既に保証されています。

于 2012-10-20T20:12:22.200 に答える
15

メソッド自体の中でJavaassertキーワードを使用して事後条件をエンコードします。

単体テストまたは事後条件?

単体テストと事後条件は異なる目的を果たします。

単体テストのアサーションは、1 つの入力ベクトルのメソッドの結果をチェックします。これは、1 つの特定のケースに対して予想される結果を指定するオラクルです。

assert メソッド自体の は、任意の入力に対して事後条件が保持されていることを確認します。これは、考えられるすべてのケースで予想される結果 (のプロパティ) を指定するオラクルです。このようなオラクルとしての事後条件は、入力を生成するのは簡単ですが、各入力の期待値を生成するのが難しい自動化されたテスト手法とうまく組み合わされます。

グアバ事後条件?

Guava に Precondition クラスがあるのに Postcondition クラスがない理由について、私の理解は次のとおりです。

Guava Preconditions は、メソッドの入力またはオブジェクトの状態に基づいて、特定の種類の例外 (不正な引数、null ポインター、範囲外のインデックス、不正な状態) をスローしたい一般的な状況の省略形を効果的に提供します。

事後条件の場合、そのような一般的なケースは少なくなります。したがって、特定の種類の例外をスローする省略形を提供する必要はほとんどありません。事後条件の失敗は、HTTP 500 の「内部サーバー エラー」のようなものです。メソッドの実行中に何か問題が発生したことはわかっています。

(Guava の前提条件の概念は、純粋なdesign-by-contractの概念とはまったく異なることに注意してください。そこでは、前提条件が満たされない場合、まったく保証がなく、合理的な例外がスローされることさえありません。Guava の Preconditions クラスは便利な機能を提供します。パブリック API をより防御的にする機能)。

于 2013-02-20T20:27:51.847 に答える
9

事前条件と事後条件は、非常に異なる目的を果たします。

前提条件は、メソッドの制御下にない入力をテストします。事後条件は出力をテストします。したがって、メソッド自体の内部では意味がなく、メソッドをテストする外部コードとしてのみ意味があります。

ただし、そのようなアサーションをコードに本当に入れたい場合は、それが意図された目的でなくても、Guava Preconditions はそのためにもかなり役立ちます。

于 2012-10-20T20:13:38.887 に答える