プロの開発者は、特別な追加の努力をすることなく、彼の仕事の過程で学ぶ知識のいくつかのカテゴリーがあります。 ここでは、例えば、ジェフリー・ファードルによる正規表現に関する素晴らしい本を読んで、同じ名前のトピックに精通している人はほとんどいません。 確かに、「レギュラー」が人生の意味になっている多くの人々がいます、そして、あなたはそのような基本的な知識なしではできません。 しかし、ほとんどの場合、ドキュメントの対応するセクションのいくつかの小さな記事とヘルプは、正規表現での作業を多少なりとも快適にするのに十分です（正規表現での「快適な作業」Jがある場合）。
同様に、私たちは通常ユニットテストの研究に関連しています。 結局のところ、単体テストはロケット科学ではありません。 彼らの研究は長年の準備を必要とせず、多くの眠れぬ夜がユニットテストの達人からの厚い「タルマッド」の研究に費やされました。 自動コードテストの概念は10分で説明できます。xUnitテストフレームワークの1つに慣れると（別の15分）、すぐに他のフレームワークを操作できます。 その後、Rhino Mocksや出来事など、ある種の分離フレームワークを勉強するためにさらに20分を費やす必要があります。ユニットテストの分野でもう1人の専門家がいます。
経験、プラグマティズム、常識に支えられたツールのこのようなレベルの所有権は、快適な作業に十分であるため、経験豊富な開発者はこの本の恩恵を受けないと思われるかもしれません。 正直なところ、私は同じ意見であり、アメリカ人の同僚のためにユニットテストに関する報告書を準備する必要がなければ、この本にほとんど興味がありません。 結局のところ、あなた自身の使用のための質問を所有することと、新しいことを導入し、開発チームの世界観を変えることです。そのほとんどはあなたの上司です。
今後、Roy Osheroveによる「 The Art of Unit Testing 」という本は、経験豊富な開発者にとっても役に立つと誤解されたと言っておく価値がありますが、まず最初にしましょう。
本の構造は、著者が最も単純で最も基本的な概念からより高度なものに行くようなものです。 すべて簡単な例と定義から始まり、TDDの紹介、アプリケーションの「継ぎ目」、およびmokiやstubsなどの「偽物」の使用について説明し、さまざまな分離フレームワークについて簡単に説明します。
ロイは最初から、重要な考えを読者の頭の中に打ち込もうとしています。高品質のテストは、高品質の製品コードと同じくらい重要です！ 「良いテストの柱」の第7章全体は、良いテストとは何かに焦点を当てていますが、その境界を越えても、「良い」テストの影は読者をほぼ絶えず悩ませます。 コードの品質について書かれた本や数え切れないほどの記事がおそらくあります。 保守が容易なコードを書くことがどれほど重要か、その品質を改善するために何をすべきかを知っています。 しかし、テストの品質に対する私たちの態度はあまり意味がありませんが、悪いテストはビジネスロジックの$＃oコードよりもあなたの人生を損なうことはありません。
あなたがこのビジネスに不慣れで、この方法で良いテストを書くことを学ばない限り、悪いユニットテストを書くことは意味がありません。 誤って不適切なテストを作成する場合は、同じ成功でこのレッスンを完全に放棄できます。 これにより、スケジュールの遅れに関連するトラブルからあなたを救い、メンテナンスに関する追加の問題からあなたを救います。
Royは、単体テストの原則に加えて、組織への単体テストの導入、レガシーコードのテスト、アプリケーション設計へのテストの影響などの重要な側面に注意を払っていることは素晴らしいことです。 設計に関して、ロイは、テスト可能な設計は主に言語またはプログラミング環境の制限によるものであり、動的プログラミング言語には存在しないと考えています（そこに何かを「閉じ込める」ことができるため）。 優れたデフォルト設計は十分にテストされており、ユニットテストを書く能力はクラスコントラクトの単純さの良い兆候であり、クラスがあまり必要ないという兆候だと信じているため、このアプローチには同意しません。
注
「理想的なアーキテクチャ」の記事で、ユニットテストを貧弱なデザインの「リトマステスト」として使用する方法について詳しく読むことができます 。
ロイ自身によると、彼は本を書くのに3年を費やしました。これは、2人の子供を「創造する」ために費やした以上のことであり、これは定期的に感じられます。 たとえば、本のさまざまな場所でクラス図の異なる形式が使用され、テストクラスとメソッドの名前が異なる場合があり、実際、deja vuの感覚が定期的に訪れます。 他にも小さな点があります。 そのため、著者は200ページでNUnitライブラリステートメントの標準構文を使用し、200ページ目からAssert.Thatを突然使用し始め、この構文がより宣言的であることを宣言します。 明らかに、本の作業が開始されてから約1年半後、Royはこの構文にたどり着き、以前の例を変更する時間と労力はなくなりました。
この本の唯一の重要な注意点は、パラメータ化された単体テストのトピックの弱い開示です。 はい、ロイはこの可能性について言及していますが、それは非常に表面的であり、本の終わり近くにあります。 作者がユニットテストの開始順序の不十分なカウントに関する4（！）ページを費やすと、2つのパラグラフがパラメーター化されたテストに費やされると、多少の不公平が感じられます。
あなたの意見が著者の意見と異なる他の点を見つけることができますが、一般的に、本「ユニットテストの技術」はユニットテストに関する最高の情報源の1つであり、正しい方向にあなたの世界観を変えるか、既存の知識をまとめて構造化します。
評価：4+
関連する関連リンク
本
Roy Osheroveによる単体テストの技術
xUnitテストパターン： Gerard Meszarosによるテストコードのリファクタリング
マイケルフェザーズによるレガシーコードを効果的に使用する
NUnitを使用したC＃での実用的な単体テスト 、Andy HuntとDave Thomasによる第2版
ポッドキャスト
JUnitの歴史とKent Beckによるテストの未来
Kent Beck、開発者テスト