Concurrency in C# Cookbook、第 2 版

第7章. テスト

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

をテストすることは、ソフトウェアの品質にとって不可欠な要素である。単体テストを提唱する人たちは近年よく見かけるようになり、あちこちで見聞きするようになった。アプリケーションの完成時に包括的なテストがあることを保証するコーディングスタイルである、テスト駆動開発を推進する人もいる。単体テストがコードの品質と完成までの全体的な時間にもたらす利点はよく知られているが、それでもまだ多くの開発者は単体テストを書いていない。

少なくとも単体テストを書くことを勧める。一番自信がないコードから始めよう。私の経験では、単体テストは主に2つの利点を与えてくれた：

• コードの理解を深める。アプリケーションの中で、動くけどどうやって動くのかわからない部分があるよね？本当に奇妙なバグレポートが来るとき、それはいつも頭の片隅にあるものだ。難しいと感じるコードの単体テストを発見することは、そのコードがどのように動作するかを明確に理解するための素晴らしい方法だ。その振る舞いを記述する単体テストを書いた後では、そのコードはもはやミステリアスなものではない。

• 変更を加える自信がつく。遅かれ早かれ、怖いコードを変更しなければならない機能リクエストが来るだろう。機能要求が来る前に、怖いコードの単体テストを書くのだ。単体テストが完成すれば、もしあなたの変更が既存の振る舞いを壊してしまったら、すぐにアラートで知らせてくれる早期警告システムができる。プルリクエストがあるとき、単体テストは、コードの変更が既存の振る舞いを破壊しないという、より大きな確信も与えてくれる。

これらの利点は、他人のコードと同じように自分のコードにも当てはまる。他にも利点はあると思う。単体テストはバグの頻度を減らすだろうか？その可能性は高い。単体テストはプロジェクト全体の時間を短縮するか？可能性はある。しかし、私が説明した利点は定義されている。私は単体テストを書くたびにそれを経験している。というわけで、これが単体テストの売り込みだ。

この章では、テストに関するレシピを紹介する。多くの開発者は（普段単体テストを書いている人でも）、並行コードをテストするのは難しいと思って敬遠している。しかし、これらのレシピが示すように、並行コードの単体テストは、彼らが考えているほど難しくはない。async 、System.Reactiveのような最新の機能やライブラリは、テストに多くの工夫を凝らしており、それが表れている。これらのレシピを使って単体テストを書くことをお勧めする。特に、並行処理に慣れていない場合（つまり、新しい並行処理コードが難しく見えたり、怖く見えたりする場合）。

7.1 非同期メソッドの単体テスト

問題

async 単体テストが必要なメソッドがある。

解決策

ほとんどの モダンな単体テストフレームワークは、MSTest、NUnit、xUnitを含むasync Task 単体テストメソッドをサポートしている。MSTestは、Visual Studio 2012でこれらのテストのサポートを開始した。他の単体テストフレームワークを使用している場合は、最新バージョンにアップグレードする必要があるかもしれない。

以下は、async MSTest単体テストの例である：

[TestMethod]
public async Task MyMethodAsync_ReturnsFalse ...