単体テストのパラメータとしてのAnyString（）

Question

テストをしていない従来のアプリケーションを扱う必要があります。したがって、リファクタリングを開始する前に、すべてがそのまま動作することを確認したいと思います。

ここで、次のような状況を想像してみてください。

public SomeObject doSomething(final OtherObject x, final String something) { 
    if(x == null) throw new RuntimeException("x may not be null!"); 
    ... 
} 

は今、私はそれが動作し、私はリファクタリングたら、私はそれを失うことはありません確かに、それはnullチェックをテストしたいです。

だから私は、これは当然のことながら働く、今、この

@Test(expected = RuntimeException.class) 
public void ifOtherObjectIsNullExpectRuntimeException() { 
    myTestObject.doSomething(null, "testString"); 
} 

をしました。

"testString"の代わりにランダムなStringを渡したいと思います。

だから私が試した：

しかし、これは許可されていない、私は

org.mockito.exceptions.misusing.InvalidUseOfMatchersException得るよう：。 を...あなたは検証の外で引数マッチャーを使用することはできませんかスタブしてください

私はこれの意味を理解していますが、私はテストなどをパラメータ化せずに私が望むことをやっていけるかどうかは疑問です。 私が使用できるライブラリは、Junit、AssertJ、Mockito、Powermockだけです。

アイデア？

Answer 1

Mockitoが例外を介してあなたに伝えようとしているように、それは実際にあなたが使用する方法ではありませんanyString。そのような方法はモックによってのみ使用される。

実際のランダムな文字列でテストしてみませんか？このようなシナリオで私の個人的なお気に入り：java.util.UUID.randomUUID().toString()。これにより、以前はあなたのテストには一度も使用されていなかったまったく新しい文字列が生成されます。

SomeObjectクラスのテストを書く場合は、SomeObjectの動作を邪魔しないようにしてください。あなたの例から、あなたはそれを正確に実行していませんでしたが、あなたがそのルートを下っているように見えました。実装自体ではなく、テストしようとしている実装の依存関係を模擬してください！これはとても重要です;それ以外の場合は、実際には何もテストしていません。

Answer 2

私はmockitoの知識はあまりありませんが、あなた自身のランダムな文字列ジェネレータをいつでも作成できます。多分それは働くことができ、それの入力のより多くのタイプを変更することができます

Answer 3

テストは決定論的でなければなりません。テストでランダムな値を使用すると、失敗したテストをデバッグするときの動作を再現することが困難になります。 "abcdefg"のように、テストの定数をStringとして作成することをお勧めします。

Answer 4

ここではコンセプトを混在させています。

anyStringのようなすべてのものを「モック」ヘルパー（）がモックオブジェクトを設定する際に使用されることを意図しています。

しかし、あなたはあなたのテストコードをチェックする場合：

@Test(expected = RuntimeException.class) 
public void ifOtherObjectIsNullExpectRuntimeException() { 
    myTestObject.doSomething(null, "testString"); 
} 

あなたは見つける：このテストに関わる全くないモックがあります。あなたは単にできませんその場所でそれらのMokito呼び出しを使用します。その場所に「モキトはありません」という理由があります。

ちょうど記録のために、とにかくここに船外に行く必要はありません。あなたのロジックはここで非常に明確です：最初の引数がnullの場合、その例外がスローされます。したがって、第二引数として来るものは本当に問題ではありません。ですから、第2引数でヌルをどのようにテストするかについて1時間考えると、私の目にはあなたの時間が無駄です。

最終ヒント：そこjava.lang.Objects され、そのクラスがnullのために素敵なチェックを持っているので、私の生産コードしかない

public SomeObject doSomething(final OtherObject x, final String something) { 
    Objects.requireNonNull(otherObject, "otherObject must not be null"); 
    Objects.requireNonNull(something, "something must not be null"); 

だけの違いのようになります。必要と...スローNullPointerExceptions

最終的に、最終的には、いくつかの人々はすべてのパラメータを最終決定することを提案します。しかし私はそれをしません。すべての症例の99％においてがの値を追加しています。これは、読み込むコードが増えたことを意味します。いい理由はありません。しかしそれはスタイルの問題です。潜在的な将来の変更を確認するためのテストを持っていることについてコメント

EDIT：あなたはそれを行うべきではありません。ある程度

1. 、あなたの入力が確認された方法は、実装の詳細です。実装の詳細はテストしません。つまり、
2. あなたのメソッドは一定の契約を結んでいます（たとえば、null入力でNPEをスローするjavadocを書いて非公式に指定する）。あなたのテストでは、が正確にであることを確認する必要があります。そして、契約は：最初の引数がnullの場合にスローされます。

さらに別の見方があります。私はまだあなたがここであなたの時間を無駄にしていると思うので！すべてのインターフェースが明確で、理解しやすく、使いやすいことを確認する必要があります。彼らはあなたのコードのユーザーが適切なことを簡単に行うことを許可します。彼が間違ったことをしないようにする。それはあなたが集中すべきものです - あなたのインターフェイス全体の品質！ 今後の変更の可能性をテストする方法を心配するのではなく、コードベース全体が一貫していることを確認してください。