2

サブタイプが常に有効なコンストラクター引数を使用することを知るために、基本クラスの前提条件を確認したいと考えています。

例として、次のコンストラクターを見てみましょう。

  1. 2 つ以上のパラメータを取ります
  2. さまざまなタイプのパラメーターを取る
  3. 1 つのパラメーターに対して、複数のチェックを実行します (たとえば、文字列が nullではなく、空でないなど) 。

その場合、Guava前提条件アプローチをどのように使用するのが最善でしょうか?

このようなモック例では: (これは不自然です!)

protected AbstractException(String errorMessage, Throwable errorCause) {
  super(errorMessage, errorCause);
  checkNotNull(errorMessage,
      ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK, "errorMessage");
  checkArgument(!errorMessage.isEmpty(),
      ErrorMessage.MethodArgument.CANNOT_BE_EMPTY_STRING_CHECK,
      "errorMessage");
  checkNotNull(errorCause, ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK,
      "errorCause");
}

への呼び出しはメソッドの最初の行である必要があるsuperため、引数をチェックする前に呼び出すことになります。したがって、ジレンマは次のとおりです。supersuper(checkNoNull(errorMessage))checkArgumentvoid

  • すべての引数のチェックはどこで行うのですか? そのためだけにビルダーを作成したくありません
  • 架空のように小切手を「グループ化」するにはどうすればよいですかcheckStringNotNullAndNotEmpty()
  • むしろ、マッチャー フレームワークとの統合を検討する必要がありますか? （ハムクレスト、フェストのアサーション...）

デフォルトにはエラーメッセージが含まれていないため、奇妙に見える ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK を使用しますthrow。テスト側からは、これを「任意の」NPE ではなく引数検証の失敗として認識できませんか?

私はそれをすべて間違っていますか？

4

1 に答える 1

1

これはコメントだったはずですが、長すぎます。

  • superスーパーコンストラクターがとにかく実行すべきでないことを実行しない限り、テストの前に呼び出すことは無害です。
  • 静的ビルダーメソッドを使用して防止できます。ビルダーは必要ありません。しかし、それだけの価値はありません。
  • グループ化テストが一般的に役立つとは思えません。もしそうなら、そのような方法はすでにあるでしょう。しかし、そのような具体的なものが2回以上必要な場合は、独自のものを作成してください。頻繁に発生する場合は、RFEとしてGuavaチームに報告してください。
  • 確かに、ここでは例外を作成しているだけなので、マッチャーはやり過ぎです。つまり、めったに使用されないものを作成しているだけです（私は願っています）。テストは実行時のみであるため、エラーを検出するのに実際には役立ちません。「適切に」構築された例外を静的に保証できればいいのですが、純粋なJavaでは不可能です。

さらに重要なこと：あなたが投げている例外は、おそらくすべてのチェックなしで得られる例外よりも劣っています。ユーザーが原因を提供し、メッセージを提供しないと想像してください。それは悪いことだと思いますが、原因のないNPEに置き換えます。それはもっと悪いです。

Guava Preconditions.format（パッケージプライベート）を見てください。最初に正しい数の引数をチェックできますが、チェックしません。提供する数が少なすぎたり多すぎたりすることはエラーですが、それを無視することが最善の処理方法です。

于 2012-10-09T21:05:19.580 に答える