1

これは未解決の質問であると思われますが、コード設計の側面に焦点を当てた回答を希望します。

回答の範囲を狭めるには：

  • クラスが具体的なクラスであるべきか、それともあまり明白でないときにモックされたインターフェイスであるべきかをどのように決定しますか。
  • 役割と責任の割り当てについて、あなたの経験はどのようなものですか。
  • 通常、どの依存関係の深さに行きますか。
  • すでに認識されているターゲット デザインが tdd プロセスにどの程度影響するか。
  • tdd 駆動型の実装を既存のコードに適合させた経験は何ですか。
  • その他の設計上の考慮事項。

ありがとう！

4

2 に答える 2

3

ボブおじさんは TDD の 3 つの法則を定義しました。

  • 失敗した単体テストに合格する場合を除き、製品コードを書くことは許可されていません。
  • 失敗するのに十分な以上の単体テストを作成することは許可されていません。コンパイルの失敗は失敗です。
  • 失敗した 1 つの単体テストに合格するのに十分な量を超える製品コードを記述することは許可されていません。

古典的な赤-緑-リファクタリング サイクルに従って、Kent Beck によって定義された単純な設計の 4 つのルールを思い出してください。リファクタリングの段階でそれらを適用します。コードは (優先順位に従って):

  • すべてのテストを実行する
  • 重複コードを含まない
  • 著者が表現したいすべてのアイデアを表現する
  • クラスとメソッドを最小限に抑える
于 2013-11-03T13:35:06.013 に答える
-1

TDD の第 0 法則:

TDD プロセスが退屈すぎるときはいつでも中断してください、くそったれ!

TDD が退屈すぎることをどのように知っていますか? 定期的に 5 分でテストを書いていて、突然、その部分のテストを書くのに 8 時間以上のシフトが必要になった場合、それはサードパーティの何かを呼び出します。単体テストは忘れて、時々手動でテストしてください。目標は、100% ではなく、95% をカバーすることです。

于 2013-11-03T18:11:10.440 に答える