1

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行います)。

4

3 に答える 3

3

これらのメソッドがすべて公開されている場合、つまり外部から呼び出し可能である場合は、完全なテスト セットを使用してすべてのメソッドを確実にテストします。もっともな理由の 1 つは、ホワイト ボックス テストがブラック ボックス テストよりも脆弱であることです。実装が変更された場合、これらのメソッドの一部についてパブリック コントラクトが変更される可能性があります。

于 2010-12-01T22:07:55.360 に答える
2

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

実装のコーナー ケースを調べるように見える 2 番目のテスト セットがあります。これはホワイト ボックス テストであり、確かに単体テストの場所があります。ホワイトボックスの実装に関する知識がなければ、興味深いパスを知ることはできません。String の場合には特に注意を払う必要があります。これは、インターフェイスが double にきれいに変換されない可能性のある文字列を許可し、精度などの境界を押し広げるためです。

整数の場合、いくつかのコーナーをカットしますか? 私は二重のケースでパスをプッシュしたことを知っています。おそらくそうすべきではありませんが、時間のプレッシャーがかかる可能性があります。

于 2010-12-01T22:15:47.843 に答える
2

場合によります。

実装は変更される可能性が高いと思いますか? その場合は、ブラック ボックス テストを行ってください。

実装が変わらないことを保証できる場合は、ホワイトボックスを使用してください。ただし、これを保証できる可能性は 100% ではありません。

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

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

于 2010-12-01T22:11:16.230 に答える