統合テストは設計をどのように批判しますか？

統合テストに関するJB Rainsbergerのブログ投稿を読んでいますが、どのように統合テストが私たちの設計により厳しいのでしょうか？

より統合されたテストを作成します。これはより大きく、マイクロテストのように設計を厳しく批判しません。

マイクロテストは、優れた設計につながる可能性があります。適切な小さなテストを作成することにより、少量のコードを意図的にテストし、そのギャップをモックオブジェクトで埋めることになります。これは、低いカップリング（相互に依存しないもの）と高い凝集性（一緒に属するものが一緒に留まる）につながります。そうすれば、戻って変更を加えたときに、探しているものの原因を簡単に見つけることができ、変更を加える際に物事を壊す可能性が低くなります。これですべてのデザインが解決されるわけではありませんが、役立ちます。

これに関連して、JB Rainsbergerは、ユニットテストの作成が難しい場合、デザインに問題が発生している可能性が高く、テストが暗黙的にデザインを批判していることに気付いています。彼は、これは良いことだと仮定します。小さなテストがなければ、アーキテクチャを維持するのに役立つため、統合されたテストでは捕捉できない優れたデザインパターンから簡単に外れてしまうからです。

更新：Rainsbergerが以下で述べているように、彼はマイクロテストを単体テストと同義語にするつもりはありませんでした。彼はまた、詳細な回答を提供してくれたので、彼が正確に伝えていたことについてより深い洞察を得ることができます。

非常に短いバージョン：システムの小さな部分を実行するため、テストが小さくなり、プログラマーが書くことができる内容が自然に制約されるため、シャープな（気付きやすく、無視しにくい）フィードバックの機会が生まれます。これは必ずしもデザインの改善につながるとは限りませんが、代わりに、デザインリスクに早く気付く機会を作り出します。

まず、明確にするために、「マイクロテスト」と言うときは「小さなテスト」を意味し、それ以上のことは意味しません。「ユニットテスト」を意味しないので、この用語を使用します。「ユニット」を構成するものについての議論に巻き込まれたくありません。私は気にしません（少なくともここ/今はそうではありません）。2人は「ユニット」よりも「スモール」の方が簡単に同意するでしょう。そのため、このアイデアの新しい標準用語として「マイクロテスト」を採用することにしました。

「アクション」部分でシステムのより大きな部分を実行するテストを意味するより大きなテストは、より小さなテストほど明確にも完全にも設計を批判しない傾向があります。テストの特定のグループに合格できるすべてのコードベースのセットを想像してください。つまり、コードを再編成でき、それでもそれらのテストに合格することを意味します。大規模なテストでは、このセットは大きくなります。小規模なテストの場合、このセットは小さくなります。別の言い方をすれば、テストが小さいほどデザインの制約が大きくなるため、デザインが少ないほど合格になります。このようにして、マイクロテストは設計をさらに批判することができます。

「もっと厳しく」と言うのは、聞きたくないが聞きたいことを直接伝え、他の人が不快に感じるかもしれない方法で緊急性を伝えるためにあなたに怒鳴る友人のイメージを思い起こさせるためです。やっています。一方、統合されたテストは静かであり、主に問題に対処する時間もエネルギーもなくなったときにのみ問題を示唆します。統合されたテストでは、敷物の下で設計上の問題を簡単に一掃することができます。

より大きなテスト（統合テストなど）では、プログラマーはだらしないことで問題を抱える傾向があります：何らかの方法でテストに合格する複雑なコードを書く自由がありますが、そのコードの理解は次のタスクに進むとすぐに消えてしまいます、および他の人はもつれたデザインを過度に読むのが困難です。ここに統合テストに依存するリスクがあります。小規模なテスト（マイクロテストなど）の場合、プログラマは主に過剰な仕様によって問題に直面する傾向があります。通常、以前のテストからのコピー/貼り付けなど、無関係な詳細を追加することでテストに過剰な制約を課します。隅に。良いニュース：書いてから数時間から数日でテストから余分な詳細を削除するほうが、書いてから数か月から数年、絡み合った量産コードを分解するよりもはるかに簡単で安全です。間違いが起こると、過剰指定はより明白な損傷をより迅速に行い、アラートプログラマーは物事を修正する必要があることを以前に認識します。私はこれを長所と考えています。問題を早期に発見し、それらの問題が機能を追加する能力を絞る前に修正します。

彼は、優れたソフトウェア設計は、統合テストよりも単体テストでよりよく知らされることを意味します。

その理由は次のとおりです。単体テストを作成すると、単体テスト可能なコードを作成する必要があります。単体テスト可能なコードは、単体テストを持たないコードよりも優れた設計になる傾向があります。

統合テストでは、ソフトウェアを相互に接続する内部インターフェイスではなく、ソフトウェアの外部層をテストしているだけなので、コードに同じ方法で通知することはありません。