6

TDDを使い始めました。以前の質問で述べたように、最大​​の難しさはインターフェースの変更を処理することです。要件の変化に応じて、テストケースへの影響をどのように減らしますか？

4

9 に答える 9

9

インターフェイスを変更するには、そのインターフェイスを使用するコードを更新する必要があります。この点では、テスト コードは非テスト コードと何ら変わりはありません。そのインターフェイスのテストを変更する必要があることは避けられません。

多くの場合、インターフェースが変更されると、「あまりにも多くの」テストが壊れることに気付きます。つまり、ほとんど関連のない機能のテストがそのインターフェースに依存することが判明します。これは、テストが広すぎてリファクタリングが必要であることを示している可能性があります。これが発生する可能性のある方法は多数ありますが、一般的な考え方と特定のケースを示す例を次に示します。

たとえば、 Account オブジェクトを構築する方法が変更され、 Order クラスのすべてまたはほとんどのテストを更新する必要がある場合、何かが間違っています。Order 単体テストのほとんどは、おそらくアカウントの作成方法を気にしないため、次のようにテストをリファクタリングします。

def test_add_item_to_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    order = Order(acct, shipping_addr)
    item = OrderItem('Purple Widget')
    order.addItem(item)
    self.assertEquals([item], order.items)

これに：

def make_order(self):
    acct = Account('Joe', 'Bloggs')
    shipping_addr = Address('123 Elm St', 'etc' 'etc')
    return Order(acct, shipping_addr)

def make_order_item(self):
    return OrderItem('Purple Widget')

def test_add_item_to_order(self):
    order = self.make_order()
    item = self.make_order_item()
    order.addItem(item)
    self.assertEquals([item], order.items)

この特定のパターンはCreation Methodです。

ここでの利点は、注文のテスト メソッドが、アカウントとアドレスの作成方法から分離されていることです。これらのインターフェイスが変更された場合、たまたま Accounts と Addresses を使用するすべてのテストではなく、変更する場所は 1 か所だけです。

要するに、テストもコードであり、すべてのコードと同様に、リファクタリングが必要な場合があります。

于 2008-09-26T14:30:15.583 に答える
7

これが、インターフェースが多用されているという流行の議論の理由の1つだと思います。

しかし、私は同意しません。

要件が変わると、テストも変わります。右？つまり、テストを作成した基準が有効でなくなった場合は、そのテストを書き直すか、削除する必要があります。

これがお役に立てば幸いですが、あなたの質問を誤解したのではないかと思います。

于 2008-09-26T13:06:24.427 に答える
4

影響があります。インターフェイスを変更すると、最初に関連するテストケースを変更するのに時間がかかることを受け入れる必要があります。これを回避する方法はありません。

ただし、後でこのインターフェイスでとらえどころのないバグを見つけようとせず、リリース週にそのバグを修正しないことで節約できる時間を考慮すると、それだけの価値があります。

于 2008-09-26T13:12:51.430 に答える
1

「コードとテストが要件に依存しないようにするために何をすべきか? 何もないように思える. 要件が変更されるたびに、コードとテストを変更する必要がある. しかし、おそらく作業を簡素化できるでしょうか? はい、できます. そして重要な原則は: 変更される可能性のあるコードのカプセル化."

http://dmitry-nikolaev.blogspot.com/2009/05/atch-your-changes.html

于 2009-06-02T11:45:10.180 に答える
1

TDD では、テストはテストではありません。実行可能な仕様です。IOW: 要件の実行可能なエンコーディングです。そのことを常に心に留めておいてください。

ここで、突然明らかになります。要件が変更された場合、テストも変更する必要があります。それが TDD の要点です。

ウォーターフォールを行っていた場合は、仕様書を変更する必要があります。TDD でも同じことを行う必要がありますが、仕様が Word ではなく xUnit で記述されている点が異なります。

于 2008-09-28T07:13:35.100 に答える
0

テストファーストのアプローチに従っている場合、理論的には、インターフェイスの変更がテストコードに影響を与えることはありません。結局のところ、インターフェイスを変更する必要がある場合は、最初に要件に一致するようにテストケースを変更してから、テストに合格するまでインターフェイス/実装を変更します。

于 2008-09-26T13:08:07.370 に答える
0

新しいインターフェイスのコードを作成する前に、テストを作成します。

于 2008-09-26T13:06:23.053 に答える
0

インターフェイスが変更されると、テストが壊れることを予期する必要があります。壊れるテストが多すぎる場合は、システムが密結合されすぎており、そのインターフェースに依存するものが多すぎることを意味します。いくつかのテストが壊れると予想する必要がありますが、多くはありません。

テストが壊れることは良いことです。コードを変更すると、テストが壊れるはずです。

于 2008-09-28T08:52:15.690 に答える
0

要件が変更された場合、インターフェイスではなく、テストを最初に変更する必要があります。

最初の適切なテストでインターフェース設計を変更することから始め、インターフェースを更新して新しく壊れたテストに合格します。インターフェイスが更新されてテストに合格すると、他のテストが壊れていることがわかります (古いインターフェイスを使用するため)。

残りの失敗したテストを新しいインターフェイス設計で更新して、それらを再び成功させることが問題になるはずです。

テスト主導の方法でインターフェイスを更新することで、変更が実際に必要であり、テスト可能であることを確認できます。

于 2009-03-18T16:56:27.593 に答える