TDD インターフェースの変更の処理

StackOverflow https://stackoverflow.com/questions/139365

  •  02-07-2019
  •  | 
  •  

質問

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

役に立ちましたか？

解決

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

インターフェイスが変更されると、「多すぎる」テストが壊れることがよくあります。ほとんど関係のない機能をテストすると、そのインターフェイスに依存していることが判明します。これは、テストの範囲が広すぎてリファクタリングが必要であることを示している可能性があります。これが起こる可能性のある方法はたくさんありますが、ここでは、特定のケースだけでなく一般的なアイデアも示す例を示します。

たとえば、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)

この特定のパターンは、 作成方法.

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

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

他のヒント

私 考える これが、インターフェイスが多用されているという最近の議論の理由の 1 つです。

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

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

お役に立てば幸いですが、質問を誤解しているかもしれません。

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

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

TDD では、テストはテストではありません。これらは実行可能な仕様です。IOW:これらは要件を実行可能なエンコード化したものです。 いつも 心に留めておきます。

さて、突然次のことが明らかになります。要件が変わるとテストが行​​われます しなければならない 変化！それが TDD の要点です。

ウォーターフォールを行っている場合は、仕様書を変更する必要があります。TDD では、仕様が Word で書かれておらず、xUnit で書かれていることを除いて、同じことを行う必要があります。

「コードとテストが要件に依存しないようにするにはどうすればよいでしょうか?何もないようです。要件が変わるたびに、コードとテストを変更する必要があります。しかし、作業を簡素化できないでしょうか?はい、できます。そして重要な原則は次のとおりです。変更される可能性のあるコードのカプセル化。」

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

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

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

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

テストが中断されるのは良いことであり、コードに変更を加えるとテストも中断されるはずです。

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

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

失敗した残りのテストを新しいインターフェイス設計で更新して、再度合格させる必要があります。

テスト駆動の方法でインターフェイスを更新すると、その変更が実際に必要であり、テスト可能であることが保証されます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top