唯一の実際のロジックは、外部APIのクエリ構文にあります。APIを照会するかどうかをテストするのではなく、正しいデータが返されるような方法で照会することをテストする必要があります。たとえば、いくつかの擬似コード：
function retrieve_related_data(id)
{
query = "[potentially long, syntactically complex query that
uses param id to get some data]";
results = api_wrapper.query(query);
return results;
}
構成されたAPIを使用したより具体的な例：
function retrieveLifeSupportingObjectsWithinRegion(id)
{
query = "
within region(" + id + ") as r
find objects matching hydration>0 and temp_range has 75
send name, id, relative(position, r)
";
results = astronomicalObjectApiWrapper.query(query);
return results;
}
クエリはAPIの構文のカスタムであり、複雑であり、同じまたは類似の結果を達成するための複数の方法があります。この関数の目的は、特定されidたデータを取得することではなく、特定されたデータとのファジー関係に基づいて他のデータのサブセットを見つけることidです。他の要件は、関係なく常に同じですidが、システムが変更されると時間とともに変化する可能性があります。たとえば、サンプルAPIで重力情報のサポートが追加された場合、結果を絞り込むために重力も使用するようにクエリを変更できます。または、温度範囲を確認するより効率的な方法を考え出すかもしれませんが、結果は変わりません。
私がテストしたいのは、与えられた入力idに対して正しいデータセットが返されることです。私はこれをテストして、誰かがクエリを台無しにして、id失敗に基づいて正しいデータを返さないようにしたいのですが、また、クエリを修正して、修正する必要なくクエリを改良できるようにしたいですテスト。
私が検討したオプション：
APIをスタブすることはできますが、それは単純すぎます（
idクエリに存在することを確認し、存在する場合は予期されるデータセットを返し、そうでない場合は予期しないセットを返します）、あまりにも脆弱です（クエリ文字列がまさに機能である）、または複雑すぎる（使用クエリは文法的に正しいことを確認し、正しいデータになります）が返されます。クエリを実際のAPIに送信することはできますが、テストシステムの制御外で外部システムのデータが変更されると、予想される結果が時間とともに変化する可能性があります。
実際のAPIのデータを制御するために、実際のAPIのテストインストールをセットアップすることもできますが、それは多大な労力です。
私は＃2に傾いており、これをより頻繁に実行されない統合テストにし、外部システムのデータの変更がテストを中断させる頻度を確認しています。今のところそれは最も簡単だと思いますが、私が考えていない代替案や、この問題に取り組むためのより良い方法があるかどうか疑問に思っています。アドバイスをいただければ幸いです。