blue-sky / prototypeプロジェクトで最初に単体テストを作成するか統合テストを作成するかを評価する

最近気付いたのは、次のタイプのプロジェクトを実行しているときです。

• プロジェクトを始めるとき
• MVP /プロトタイプの作業
• 完全に定義されていない機能を追加する
• 小規模プロジェクトでの作業

参考までに、私は現在、いくつかのコメントとすべての空白を含む、現在〜1k行のコードがあるPythonプロジェクトに取り組んでいます。

私は、コードの最初の書き込みの統合テスト、仕事にそれが非常に簡単に見つけて、その後、それ一度APIは、多少のユニットテストを追加することで、実際に作業を硬化させます。私のmain関数で実行できるテストの種類、いわば、何よりも「エンドツーエンド」です。

これは、APIがかなり急速に変化しているときにユニットテストが本当に煩わしいためです。これは、上記の条件のいずれかまたはほとんどに一致するプロジェクトで作業している場合によくあります。

このアプローチは良いアプローチですか？これらのタイプのプロジェクトの最初に単体テストと統合テストのどちらを開始するかを決定するとき、どの基準を考慮する必要がありますか？APIがより強固になる前に、この種のプロジェクトを単体テストすることの価値を見逃していますか？

APIがより強固になる前に、この種のプロジェクトを単体テストすることの価値を見逃していますか？

いいえ、元気です。

TDDの2つの大きな目的は次のとおりです。

• 内部実装ではなく、実際の使用法によるインターフェースの定義¹
• テストカバレッジの最大化

どちらの方法でも、テストカバレッジは十分に最大化できます。つまり、最初に小さな「孤立した」ユニットをテストするか、大きな「統合」ユニットをテストするかに関係なく、実装の前にテストを作成するオプションがあります。

上位レベル（「統合」）テストを最初に作成する際に得られるのは、上位レベルのインターフェースと相互作用も、内部実装ではなく、主にその使用法に従って定義されるという保証です。

同じ効果は、いくつかの優れた「アーキテクチャ」と図表を使用してほぼ達成できます。しかし、これらの高レベルのテストでは、ダイアグラムで見逃したことや、「アーキテクチャ」の作業で間違ったことが明らかになることがよくあります。

実際にTDD（またはそのようなもの）を実行していない場合、テストを作成する順序はそれほど重要ではありません。インターフェイスはテストする時点ですでに存在しているため、テストによって何かが変更される可能性ははるかに低くなります。これらのインターフェイスは、特定の重大な変更から保護するためだけに機能します。

ただし、実装をトップダウンとボトムアップで構築することに関心がある場合は、最初の箇条書きが依然として大部分に当てはまります。高レベルのコードは、低レベルのインターフェースを定義するのに役立ちます。一方、低レベルのインターフェースが最初に記述されている（またはすでに存在している）場合は、高レベルのコードが適切に処理されます...

^{1.これは、完全なTDDを実行していない場合でも適用されます。実装前に 1つまたは2つのテストを作成しているだけでも、これらの1つまたは2つのテストは、手遅れになる前にインターフェースを定義または改良するのに役立ちます。}

私はあなたが働いている方法で働いてきました。そして、私はあなたができないことをあなたに言うつもりはありません。遭遇する可能性があることについて警告します。

すべての単体テストが単に改造である場合、それらを柔軟にすることを学ぶのは困難です。それらは回帰テストに過ぎない傾向があります。リファクタリングにそれらを使用したことがないので、実際にリファクタリングを困難にする種類のテストを書くのは非常に簡単です。これは、TDDへのすべての信頼を失うまで、制御不能になりがちです。

しかし、あなたはすでに何かに取り組んでいます。止めるように言うつもりはない。最初から赤い緑のリファクタリングサイクルを探索し、それに従う時間のある何かを開始することは価値があると言えるでしょう。実際にテストを使用して、リファクタリングを支援してください。この作業方法を習得するまでは、重要なことには慎重に使用してください。これはコーディングの方法がまったく異なり、慣れるまでに時間がかかります。途中でやると、誰の役にも立ちません。

それは言った

最初に統合テストを記述してコードを処理し、APIがある程度強化されたら、実際に単体テストを追加する作業が非常に簡単であることがわかりました。私のメイン機能で実行できるテストの種類、いわば「エンドツーエンド」です。

単体テストは、1つのクラスに作用する単なるテストではないことを理解してください。作業しているAPIを次のいずれも実行せずにテストできる限り、単体テストを問題なく実行できます。

• データベースと通信します
• ネットワークを介して通信します
• それはファイルシステムに触れます
• 他の単体テストと同時に実行することはできません
• 実行するには、環境に特別な処理（構成ファイルの編集など）を行う必要があります。

Michael Feathers：ユニットテストルールのセット

したがって、エンドツーエンドのテストに複数のオブジェクトが含まれる場合は問題ありません。これはオブジェクトテストではなく単体テストです。

プライベートメソッドをテストする必要がなくなり、それを使用するパブリックメソッドをテストしてテストするように、オブジェクトを最初に独自のテストハーネスで開発する必要はありません。エンドツーエンドのストーリーとは関係なくオブジェクトの使用が検討されている場合にのみ、オブジェクトを確認するための独自のインターフェイスと動作があるように扱う必要があります。注意を払っているのは、これらのオブジェクトを公開するときです。このようにして、テストしていない約束はありません。