1

ウィキペディアによると、TDD の手順は次のとおりです。

ステップ 1: 単体テストを作成する

ステップ 2: 単体テストを実行する

ステップ 3: モジュールのコードを書く

ステップ 4:すべてのテストを再度実行する

ステップ 5: コードをクリーンアップする

ステップ 6: ステップを繰り返す

質問 1 : TDD では、主に単体テストを作成します。統合テストとシステム テストは、上記のステップのどこに当てはまりますか?

次の例を検討してください。

開発しなければならない機能があるとします。次に、TDD に従って、短いイテレーションでこの機能を開発します。この機能をモジュール 1 とモジュール 2 の 2 つのモジュールに分割したとします。上記の手順に従って、TDD でこれらのモジュールを開発するための反復手順を記述しています。(質問 2) 次の手順で間違っているところを訂正してください。

**反復 1: **

ステップ 1: モジュール 1 の単体テストを作成します。

ステップ 2: モジュール 1 に対してこの単体テストを実行します (このテストは失敗します)。

ステップ 3: モジュール 1 のコードを開発します。

ステップ 4: モジュール 1 の単体テストを再度実行します (このテストはパスします)。

**反復 2: **

ステップ 1: モジュール 2 の単体テストを作成する

ステップ 2: モジュール 2 の単体テストを実行する

ステップ 3: モジュール 2 のコードを書く

ステップ 4: モジュール 1 の単体テストとモジュール 2 の単体テストを実行します。モジュール 2 がモジュール 1 の機能を壊さないかどうか、私の質問は、ここではモジュール 2 のみをテストしていることです。まだモジュール 1 と統合されていないので、モジュール 1 をどのように壊しますか?)

**反復 3: **

ステップ 1: 統合テストを作成する (ここにいますか? )

ステップ 2: 統合テストを実行します (モジュール 1 とモジュール 2 がまだ統合されていないため、テストは失敗します)。

ステップ 3: モジュール 1 とモジュール 2 を統合する

ステップ 4: すべてのテストを実行する (モジュール 1、モジュール 2 の単体テスト、および統合テスト)

(質問 4: なぜこのステップでモジュール 1 と 2 の単体テストを実行するのですか?)

反復 4 (すべてのモジュールが統合されている場合):

ステップ 1: システム テストを作成する

ステップ 2: システム テストを実行します (失敗します)。

ステップ 3: (質問 5:) システム テストに関しては、ここにどのコードを記述すればよいですか? TDD の原則に従って、最初にテストを記述し、次に開発コードを記述するので、ここにどのコードを記述しますか?

4

2 に答える 2

7

私の意見では、ワークフローが少し後退しています。優れた本であるGrowing Object Oriented Software Guided By Testsでは、より高いレベルのテスト、多くの場合、追加したい機能を表す「統合テスト」から始めることをお勧めし、これを追加したい動作のドライバーにします。見る。

この統合テストに合格すると、機能が完成したことがわかります。

この失敗したテスト (作成者は外側のループと呼んでいます) を取得したら、内側のループで TDD プロセスを開始します。つまり、必要な機能を実装するために必要なクラスのテストを作成します。これを行うには、テストを作成し、それを通過させるコードを記述します。次に、すべてのテストを実行します。外側のテストはまだ失敗する可能性があります。次に、別の単体テストを実装してから、必要な実装を実装します。外側のテストに合格するために必要なクラスをすべて作成するまで、このプロセスを繰り返します。

次に、新しい外部テストを作成して、このプロセス全体をもう一度繰り返します。

私にとって最も重要なことは、自分に合ったプロセスを見つけて、現実的になることです。どんな独断的なアプローチも強制しないでください。ソフトウェアを書くことは、何を書くか、一緒に書く人、利用できるツール、その他多くの要因によって異なります。自分自身の経験だけでなく、一緒に仕事をし、尊敬している人々の経験に基づいて、常に自分自身のプロセスを変更し、常に再評価する準備をしてください。物事は常に良くなる可能性があるため、誰も完璧な解決策を持っているわけではありません。

Rhino Mocks を書いた人は、もはやモッキング フレームワークをほとんど使用しないと述べています。.NET で Dependency Injectionを作成した人物は、 IoC コンテナーを使用することはほとんどなくなったと述べています。柔軟で実用的であること。

単体レベルのテストよりも外側の統合テストに重点を置く傾向があることがわかりました。これにより、テストは実装ではなくコードの動作をテストするようになるからです。実際のクラスごとに 1 つのテスト クラスがあると、すべてのクラスを変更する必要があるだけでなく、すべてのテストを同時にリファクタリングする必要があるため、コードをリファクタリングするのに非常にコストがかかることがわかりました。テストがコードの論理ユニットの動作に焦点を当てている場合、通常、そのコードのクラス構造をリファクタリングすると、外部の動作ではなく内部構造のみを再編成しているため、テストは同じままです。

BDDについて@CarlManasterが言ったことも非常に関連性があります。BDD は TDD よりも有用であると思います。これは主に、テストから動作に重点が移ったためです。振る舞いはあなたが望むものであり、大規模なテストスイートではありません (ただし、それは良いこともあります)。

どのテストを実行するかについては、私にとっては、より頻繁に実行できるテストが多ければ多いほど良いです。「孤立した」変更が、不可解にも他の何かを壊す可能性があるのは驚くべきことです。システム全体のすべての変更の結果を頭の中に保持することは、小規模なシステムでさえ考えられるほど単純ではありません。

私のお気に入りのツールはNCrunchです。コーディングの停止/ビルド/実行テスト部分を削除します。テストを書き、コードを書くだけです。数秒待ちます。緑に行く。繰り返す。人生が変わった; 彼が請求する金額の2倍の価値があります。

于 2015-08-04T09:47:25.270 に答える