ユニットテストはブラックボックステストかホワイトボックステストですか？

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

これらのメソッドのすべてが公開されている場合、つまり外部から呼び出し可能な場合は、すべてのテストで完全にテストします。ホワイトボックステストはブラックボックステストよりも脆弱です。実装が変更された場合、公開契約はこれらのメソッドの一部で変更される可能性があります。

Answer 2

によって異なります。

実装が変更される可能性はありますか？その場合は、ブラックボックスのテストに行く。

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

ブラックボックステストのいくつかを妥協して、特に境界条件の周りで行うことができます。しかし、テストを書くことは容易でなければなりません。したがって、ではなく、ブラックボックスの完全なテストを行っているの観点から言い訳はありません。唯一の制限要因は、テストを実行するのにかかる時間です。

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

Answer 3

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

実装のコーナーケースを見ていると見ることができる2番目のテストセットがあります。これはホワイトボックステストであり、確かに単体テストの場所を持っています。ホワイトボックス実装の知識がなくても興味深いパスを知ることはできません。私はString型のケースに特に注意を払うでしょう。インタフェースが、double型に変換できない文字列を許容し、精度等の境界を押し出すことができるからです。

整数の場合、いくつかのコーナーを切りますか？私は二重の場合にパスをプッシュしたことを知っています、おそらく時間の圧力の下ではないかもしれません。