-3

KentBenk を例に、TDD によるテスト駆動開発を読んでいます。

--->ストレス--------$----->RunTests |
|<------------$--------|

上の図は、$ の付いた矢印が最初のノードの増加が 2 番目のノードの減少を意味する場合を示しています。

上記は正のフィードバックループです。ストレスを感じれば感じるほど、テストが少なくなり、エラーやストレスが増えます。

このようなループから抜け出すにはどうすればよいでしょうか。ここで著者は、新しい要素を導入するか、要素の1つを置き換えるか、矢印を変更することを述べました. この場合、テストを自動テストに置き換えます。

以下は、図の後のテキスト ノートです。

その変更で何か他のものを壊しただけですか？自動テストでは、ストレスを感じ始めたらテストを実行します。すぐにテストを実行すると、気分が良くなり、エラーの数が減り、ストレスがさらに軽減されます。

「テストを実行する時間がありません。ただリリースしてください!」2番目の写真は保証されません。ストレスレベルが十分に高くなると、それは崩壊します。ただし、自動テストでは、恐怖のレベルを選択する機会が必要です。

私の質問は

  1. 新しい要素の自動テストで新しいフィードバックを表すことができる人はいますか? ここで、私がストレスを感じたときに、上の図を使用して自動化されたテストの実行を減らし、ストレスを軽減する方法を教えてください。

  2. 「2 番目の図は保証されていません。ストレス レベルが十分に高くなると、それは崩壊します。ただし、自動テストでは、恐怖のレベルを選択する機会が必要です。」とはどういう意味ですか?

4

1 に答える 1

1

本を手元に持っていない..しかし、あなたの引用された一節から。

迅速な自動テストにより、次のことが可能になります。

  • 迅速なフィードバックを得る (変更を行ってから数秒以内) - 以前は機能していたものを壊してしまいましたか?
  • 頻繁に実行します..理想的には、小さな変更ごとに実行します。テスト スイートが高速であるほど、テストが頻繁に実行される可能性が高くなります。

手動テストとの違いは、フィードバック サイクルが長すぎるため、すべてのテストに 1 日または 1 週間を費やす前に多くの変更をまとめてしまうことです (小さな変更ごとに 1 日または 1 週間を無駄にしたくはありません)。これにより、欠陥が見つかったときに変更を分離するという問題が発生し、ストレスが増大します。

于 2012-12-13T05:15:52.870 に答える