1

私が TDD に惹かれる理由の 1 つは、実装と並行して仕様を明確に開発できることです。

構成オブジェクトを受け入れるコンストラクターを実装しようとしています

function MyConstructor(conf) {}

confは現在、 と の 2 つのキーを持つように仕様化されています。ここで、はaでaあり、 であり、私の TDD 仕様解明の野望の一環として、このオブジェクトを次のように仕様化するテストを作成しています。baRegExpbFunction

  • どちらかが a でないか、 a でない場合MyConstructorに をスローしたいと思います。ErroraRegExpbFunction
  • MyConstructorErrorまたは のいずれaかが構成にない場合にスローbします。

Configurationこれで、この動作を他のコンストラクター、たとえば「構成」オブジェクトを作成するコンストラクターにカプセル化できることがわかりました。しかし、私が今これを見ている方法では、この動作がどこで終わるかに関係なく、この動作は、この仕様が TDD を介して作成されるようにどこかにカプセル化する必要があります。

conf問題は、オブジェクトのキーの数が増えると、テストの数も指数関数的に増加するように私には思えます。これは、特に上記の 2 番目の箇条書きによるものです。

たとえば、 、 、 の 4 つのキーがaあるbとcしdます。不足しているキーがある場合はエラーがスローされるようにする必要があります。これには、欠落しているキーのすべての可能性 (組み合わせ!) をカバーする大量の同一の平凡なテストを作成する必要があるようです。それは正しく聞こえません！しかし、すべてのシナリオがカバーされていることを明示的または帰納的にテストする良い方法は思いつきません。何かご意見は？

4

2 に答える 2

1

クラス定義やインターフェースのないオブジェクトはテストが困難です。オブジェクトがアヒルの場合は、ダックタイピングを使用して確認する必要があります。

また、特定の機能を完全にテストすることがどれほど役立つか疑問に思うかもしれません。境界をテストすることはできますが、すべての値をテストすることはできません。

関数が次のようになっている場合:

function sum(a, b) {
    if (a === 42) {
        throw new Error("All glory to the hypnotoad");
    }
    return a + b;
}

このバグをどのように見つけることが期待されますか?

于 2013-08-08T16:05:49.973 に答える