クロスランゲージテスト駆動開発

短い質問：複数の言語にまたがるプロジェクトでテスト駆動開発をどのようにフォローしますか？

具体的には、JavaScriptとPHPを使用するWebアプリケーションを作成していて、TDDの原則に従いたいのですが、それらを統合する方法がわかりません。JSセクションとPHPセクションで別々のテストスイートを実行し、JSスイートのモックを使用してサーバーの応答をエミュレートしますか？1回の実行で両方のコンポーネントを単体テストする手法はありますか？

これは、テスト駆動開発を使用した私の最初の経験なので、困難を少なくする方法について共有できるアドバイスがあればすばらしいでしょう。私がそれを選んだ理由は、プロトタイプが完成するとすぐに要件が変更され、設計を変更せざるを得なくなったためです。最初からやり直すのであれば、最初から組み込みの回帰テストを使ってより拡張可能なコードを書きたいと思っていました。

PHPテストはSimpleTestで、JavaScriptテストはJsTestDriverで作成しています。私はオブジェクト指向のパラダイムに慣れているので、PHPにはいくつかのクラスがあり、JavaScriptではプロトタイプ継承を使用して同様のことをしています。また、PythonでのTDDに関するこの本とJavaScriptでのTDD に関するこの本も読み始めましたが、これらすべては、Seleniumや別のWebドライバーなどを使用する以外のアプリケーションの完全なテストについては説明していません。フロントエンドの受け入れテストを実行するためにTDDはフルスタックの開発者のために切り取られていないだけですか？

1回の実行で両方のコンポーネントを単体テストする手法はありますか？

それは実際の反対になるユニット、特にTDDのスタイルで、中にあなたのコンポーネントをテストするための手段ユニットテスト-テストの隔離。したがって、答えは「はい、JSセクションとPHPセクションで別々のテストスイートを実行する」です。それ以外の場合は、単体テストではなく、TDDではありません。

もちろん、自動化された統合テストでは「両方のコンポーネントを1回の実行で」テストでき、すでに述べたツール（Seleniumなど）を正確に利用できます。ただし、これらは通常、TDDサイクルの外部で開発されたより複雑なテストです。

重要なことは、TDDとATDDを区別することです。そこにあるATは「受け入れテスト」を表しており、これは最初に受け入れテストから始める開発を指し、スタック全体をテストする可能性があります。これは、「アウトサイドインテスト駆動開発」とも呼ばれます。人々がTDDについて話すとき、そこの「T」はおそらく特にユニットテストを指します。

単体テストの重要な部分は、テスト対象のユニットを依存関係から分離することです。これには2つの非常に重要な利点があります。

• テストを非常に高速にできるため、非常に短いフィードバックサイクルの一部として非常に頻繁にテストを実行できます。たとえば、1時間ごとに実行するのではなく、小さな変更ごとにすべての単体テストを実行できるようにする必要があります。そのため、その変更によって何か問題が発生したかどうかに関するフィードバックを即座に得ることができます。

• テストは、非常に特定の動作を同時に対象にすることができます。それらの1つが失敗した場合、テストが示しているバグの正確な性質をほぼ瞬時に判別できるはずです。

この分離の重要性のため、言語の境界で強制されるよりもはるかに小さな単位にテストを自動的に制限する必要があります。これは難しい規則ではありませんが、多くの場合、単一のクラスがテスト可能なユニットであると予想されます。TDDに関しては、言語の問題は多かれ少なかれ無関係です。

一方、ATDDを実行したい場合は、このためのリソースを具体的に確認してください（BDDの一部として行われることが多いため、それを対象としたツールも確認してください）。ここにSeleniumのようなものが自然に収まります。通常、ATDDを実行するときも、単体テストを作成します。実際、各受け入れテストに合格するために、単体テストを使用してその実装をテストすることもできます。したがって、ATDDを実行したい場合でも、単体テストの作成方法を理解することは依然として重要です。

また、アプリケーションの完全なスタックにTDDを使用する必要はありません。開発方法論としてのTDDは、アプリケーションのロジック部分により適しています。フロントエンドの設計、特定の相互作用、またはデータベースドメインのように、より実験的なタッチが必要な部分は、それが最終バージョンになるかどうかまだわからないため、従来のスタイルで行う方がよいでしょう。

しかし、アプリケーションのロジックは将来変更されないはずであり、変更された場合、非常に恐ろしい要件に直面することになります。これは、一連の回帰テストがTDDの最終目標であるコードに変更を加えるたびに自信を与えるのに最適です。

ボブおじさんは私よりこの方法をよく説明しています。 https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html