ユニットテストはブラックボックステストまたはホワイトボックステストである必要がありますか？

Question

私には3つの方法があり、すべて非常に似ていますが、入力タイプが異なります。

void printLargestNumber(int a, int b) { ... }
void printLargestNumber(double a, double b) { ... }
void printLargestNumber(String numberAsString, String numberAsString) { ... }

3つすべてが同じ基礎となるロジックを使用します。例：多分 double バージョンは数字を比較する唯一のものであり、他の2つは入力をに変換するだけです double.

いくつかの異なるユニットテストを想像できます。最初の入力は大きく、2番目は大きく、両方の入力は負などです。

私の質問

3つの方法すべてがテストの完全なセットを持っている場合（コア実装が同じだとは思わないため、ブラックボックス）

また

ただしてください double バージョンを頻繁にテストし、他の2つを軽くテストしてパラメーター変換を確認します（ホワイトボックステストは同じ実装を共有しており、すでにテストされているため、既にテストされています。 double テスト）？

Answer 1

これらの方法がすべて公開されている場合、つまり外の世界で呼び出すことができる場合、私はそれらすべてを完全なテストでテストすることは間違いありません。正当な理由の1つは、ホワイトボックステストがブラックボックステストよりも脆弱であることです。実装が変更された場合、公開契約はこれらの方法のいくつかについて変更される可能性があります。

Answer 2

場合によります。

実装が変更される可能性が高いと思いますか？もしそうなら、ブラックボックステストを使用してください。

実装が変更されないことを保証できる場合は、白いボックスで移動します。ただし、これを保証できる可能性は100％ではありません。

特に境界条件の周りで、ブラックボックステストの一部を妥協して実行できます。ただし、テストを書くのは簡単なはずです。そのため、その観点からの言い訳はありません いいえ 完全なブラックボックステストを行う。唯一の制限要因は、テストの実行にかかる時間です。

おそらく、テストを並行して実行する可能性を調査する必要があります。

Answer 3

公共インターフェイスを明示的に行使する一連のテストがあります。それらをブラックボックステストとして扱います。

実装のコーナーケースを見ると見られるテストの2番目のセットがあります。これはホワイトボックステストであり、確かにユニットテストの場所があります。ホワイトボックスの実装知識がなければ、興味深いパスを知ることはできません。インターフェイスは、きれいにダブルに変換できない文字列を許可し、精度などの境界を押し広げることができるため、文字列ケースに特に注意を払います。

整数の場合にいくつかのコーナーを切ってみませんか？私はダブルケースでパスを押したことを知っています。おそらく時間のプレッシャーの下で十分にうまくいくべきではありません。