TDDを使用して初期APIを正しく取得する方法

私はTDDでの最初の試みであるので、これはかなりばかげた質問かもしれません。私はそれがもたらす自信とコードの一般的な構造が大好きでしたが、1クラスのおもちゃの例よりも大きなものに適用し始めたとき、私は困難に直面しました。

ある種のライブラリを作成しているとします。あなたはそれが何をしなければならないか、それがどのように実装されるべきかについての一般的な方法を知っています（アーキテクチャ上）、しかしあなたはあなたがコードとしてあなたのパブリックAPIに変更を加える必要があることを「発見」し続けます。おそらく、このプライベートメソッドを戦略パターンに変換する必要があり（テストでモックされた戦略を渡す必要があります）、おそらく責任をあちこちに置き忘れて、既存のクラスを分割する必要があります。

既存のコードを改良する場合、TDDは非常に適しているように見えますが、最初からすべてを記述する場合、テストを作成するAPIは、事前に大きな設計を行わない限り、少し「ぼやけ」ます。シグネチャ（およびその部分の動作）が変更されたメソッドで既に30のテストがある場合はどうしますか？それは一度追加すると変更する多くのテストです。

あなたは何を呼び出す「アップフロントの大きなデザイン」私は呼んで「あなたのクラスのアーキテクチャの賢明な計画を。」

単体テストからアーキテクチャを成長させることはできません。ボブおじさん もそう言っています。

アーキテクチャを考えていない場合、代わりにアーキテクチャを無視し、テストを一緒に投げてそれらを通過させるのであれば、建物にとどまることを可能にするものを破壊することになりますシステムの構造と、システムの構造的完全性を維持するのに役立つ堅実な設計上の決定。

http://s3.amazonaws.com/hanselminutes/hanselminutes_0171.pdf、ページ4

構造設計を検証するという観点からTDDにアプローチする方が賢明だと思います。テストしなかった場合、デザインが正しくないことをどのように確認しますか？また、元のテストも変更せずに、変更が正しいことをどのように確認しますか？

ソフトウェアは、変更される可能性があるため、「ソフト」です。変更の量に不安がある場合は、引き続きアーキテクチャ設計の経験を積んでください。アプリケーションアーキテクチャに加える必要のある変更の数は、時間の経過とともに減少します。

TDDを行う場合。テストによって駆動されない限り、署名と動作を変更することはできません。したがって、失敗した30のテストは、プロセスで削除されるか、コードとともに変更/リファクタリングされました。または、それらは廃止され、削除しても安全です。

赤緑リファクタリングサイクルで赤を30回無視することはできませんか？

テストは、運用コードと一緒にリファクタリングする必要があります。余裕がある場合は、各変更後にすべてのテストを再実行します。

TDDテストを削除することを恐れないでください。一部のテストでは、目的の結果を得るためにビルディングブロックをテストします。機能レベルでの望ましい結果が重要です。選択/発明したアルゴリズムの中間ステップに関するテストは、結果に到達する方法が複数ある場合、または最初に行き止まりになった場合、あまり価値がない場合もあります。

いくつかの適切な統合テストを作成し、それらを保持し、残りを削除できる場合があります。それは、裏返しにするかトップダウンにするか、そしてどの程度のステップを踏むかによって多少異なります。

Robert Harveyがちょうど言ったように、おそらく、異なる概念ツール（つまり、「設計」または「モデリング」）で処理されるべきものにTDDを使用しようとしています。

システムを非常に抽象的な（「一般」、「あいまい」）方法で設計（または「モデル」）してみてください。たとえば、車をモデル化する必要がある場合は、startEngine（）やint seatsなどの曖昧なメソッドとフィールドを持つ車クラスを用意します。つまり、どのように実装したいかではなく、公開したいものを記述します。基本的な機能（読み取り、書き込み、開始、停止など）だけを公開し、クライアントコードをその上に残してください（prepareMyScene（）、killTheEnemy（）など）。

この単純なパブリックインターフェイスを想定したテストを書き留めます。

必要に応じて、クラスとメソッドの内部動作を変更します。

パブリックインターフェイスとテストスイートを変更する必要がある場合は、やめてください。ほとんどの場合、これはAPIおよび設計/モデリングに何らかの問題があることを示しています。

APIを変更することは珍しいことではありません。1.0バージョンのほとんどのシステムは、APIの変更の可能性についてプログラマ/ユーザーに明示的に警告します。それにもかかわらず、APIの変更の制御されていない継続的なフローは、悪い（または完全に欠落した）デザインの明らかな兆候です。

ところで：通常、メソッドごとにほんの一握りのテストが必要です。メソッドは、定義により、ある種のデータに対して明確に定義された「アクション」を実装する必要があります。完全な世界では、これは単一のテストに対応する単一のアクションでなければなりません。現実の世界では、同じアクションの異なる「バージョン」がほとんどなく、対応する異なるテストがほとんどないことは珍しいことではありません。確かに、同じメソッドで30のテストを行うことは避けてください。これは、メソッドがあまりにも多くのことを行おうとしていることを示す明確な兆候です（そしてその内部コードは制御不能になります）。

ユーザーの観点から見ます。たとえば、APIを使用して名前と年齢のPersonオブジェクトを作成できる場合、名前と年齢のPerson（string name、int age）コンストラクターとアクセサーメソッドが必要です。名前と年齢の有無に関係なく、新しいPersonsのテストケースを作成するのは簡単です。

ダグ