私はテスト駆動開発を実験していますが、次のような状況に陥ることが多いことがわかりました。

1. 一部の機能Xのテストを作成します。これらのテストは失敗します。
2. Xを実装しようとしているときに、コードの下位層に機能Yを実装する必要があることがわかりました。そう...
3. Yのテストを作成します。XとYの両方のテストが失敗します。

一度に異なるコードレイヤーで4つの機能を同時に使用すると、実際に実行していることに集中できなくなりました（同時に失敗するテストが多すぎます）。

テストの作成を開始する前であっても、タスクの計画にもっと力を入れることでこれを解決できると思います。しかし、いくつかのケースでは、例えば、下層のAPIをあまりよく知らなかったので、もっと深くする必要があることを知りませんでした。

そのような場合はどうすればよいですか？TDDには推​​奨事項がありますか？

良い点は、テスト対象のコードに支援が必要であることを認識していることです。すぐに実装するのではなく、インターフェイスを作成し、モックを使用して、テストが正しいコードを調整していることを確認してください。これらのテストに合格すると、依存するコードの実装に進むことができます。

スタブとモックを使用して、まだ変更/実装されていない機能をシミュレートできます。また、この種の「連鎖反応」を引き起こす依存関係を解決するのにも役立ちます。

一方、次の変更を実行する（失敗した）テストを1つだけ保持するのが最善の方法かもしれません。

新しい機能に依存するコードを対象とする他のテストは、この時点では実際には関連がないため、一時的に無効にすることができます。あなたの場合、Yなどを実装するまでXのテストを無効にします

そうすることで、次の変更にのみ集中することができます。

やめる

ちなみに、ここには2つの個別の問題があるように見えます。

1. いくつかのストーリーとテストシナリオを忘れ、特定のテストシナリオで作業を開始するまでそれらを発見しなかった、および/または

2. TDD 機能テストではなく、実際にユニットテストを行っています

＃1の場合、停止し、戻って、ストーリーとテストシナリオを更新してから、別のシナリオでやり直します。

＃2の場合、停止、ユニットではなく機能をテストしていることを忘れないでください。そのため、モックを使用して他のインターフェイスをグロスしたり、新しいテストシナリオを追加せずにテストをパスするコードを実装したりします。これは、テストシナリオが欠落していないことを前提としていますが、代わりに-これが実際に一般的である-単体テストとTDDを融合しています。

これはTDDにとっても大きな疑問であり、大きな不満でもあります。このシナリオでは、開発を開始するまでに必要な下位レベルのコンポーネントまたは機能を知る方法がまったくないTDDが不足しているように感じます。

個人的に、TDDは、機能を実行するために何をする必要があり、何を呼び出す必要があるかを正確に知っている場合にのみ機能することがわかりました。開発者は始める前にすべてを常に知っているわけではないので、あなたが説明するまさにその状況を緩和するための自分にとっての最良の方法であることがわかりました。

プロトタイプ

簡単なプロトタイプアプリを作成して、技術的な問題への方法とアプローチを探求し、発見すると、多くの脚の仕事を発見し、その研究を開始する前に邪魔にならないようにします。設計と見積もりも同様に簡単になります。

プロトタイプが非常に複雑であるためにアプリケーションになる場合は、怠thingなことはせず、事実の後にプロトタイプの単体テストを作成することをお勧めします。

その時点で低レベルAPIについて詳しく知り、高レベルコンポーネントで低レベルAPIを正常にモックできるようにする必要があります。

それは、TDDを行っている間にどのようなテストを書くかによって異なります。

古典的なモデルは、単体テストを記述し、モックまたはスタブを使用して、テストをコードの他の「ユニット」から切り離します。

ATDDなど、フルスタックテストまたはほぼフルスタックテストを行う代替モデルが他にも多数あります。この特定のケースでは、必要なプログラムの動作を1つのコード単位ではなくアサートするテストを書くので、他のテストを書くことはありません。テストを満たすために、ラウンドトリップを実装します。次に、他の機能/動作のために他のテストを追加します。