悪のユニットテストの記事を読んで、なぜユニットテストがDB、ネットワーク、またはファイルシステムを決して使用してはならないのか正確にはわかりません。ネットワークアプリの場合はどうなりますか?
2 に答える
単体テストは、コードの最小単位の機能をテストするために使用されます。将来変更される可能性のある外部リソースに依存してはなりません。
例を挙げると、今日、2つの数値の加算を実行するメソッドをテストする単体テストを作成するとします。
public void AddNumberTest()
{
int a = 4; // Assume 4 coming from a database.
int b = 5; // Assume 5 coming from a database.
int c = a + b;
Assert.True(9, c);
}
これは今日実行されます。それは完全にクールです。
明日来て、Addメソッドの機能を変更するとします。これで、テストを実行できるようになり、合格するはずです。しかし、どういうわけかデータベースサーバー(または外部リソース)がダウンしていると仮定しましょう。その後、テストは失敗します。
誰かがデータベースの値を変更した場合でも、テストに加えられる変更に注意する必要があります。
それはあなたが望むものですか?絶対違う。右
そのため、外部リソースから独立している必要がある単体テストケースを作成します。モックとスタブを使用する場所。
単体テストを1000回実行できるはずであり、常に同じ結果が得られるはずです。
単体テストは、アプリケーションの完全な機能をテストすることを目的としたものではありません。これは、コードの定義可能なモジュールが期待どおりに機能することを確認することを目的としています。アプリケーションをテストするには、単体テストを使用するだけでは不十分です。また、機能テストと回帰テストを実行する必要があります。データベースアクセスは単体テストの範囲外であるため、データベースアクセスを含む単体テストを作成することはありません。機能テストにデータベースアクセステストを含めます。同様に、ネットワークアプリを使用している場合は、単体テストにネットワークアクセスを含めません。どちらの場合も、シミュレートされた既知のデータを使用してデータベースまたはネットワークから取得したデータを操作するコードを単体テストし、実際のアクセスを除外します。
繰り返しになりますが、アプリを単体テストするだけでは不十分です。