統合テストは設計をどのように批判しますか？
統合テストについて J.B。Rainsbergerのブログ投稿 を読んでいますが、統合テストはどのように設計に厳しいのでしょうか。
より統合されたテストを作成します。これは大きく、マイクロテストほど厳しく設計を批判しません。
マイクロテストは 良い設計につながるのを助ける です。適切な小さなテストを作成することにより、意図的に少量のコードをテストし、そのギャップを mock objects で埋めます。これは、低結合（物事は互いに依存していない）と高凝集度（一緒に属している物は一緒に留まる）につながります。こうすることで、戻って変更を加えるときに、探しているものの原因を簡単に見つけることができ、変更を加える際に問題が発生する可能性が低くなります。これはすべてのデザインを解決するわけではありませんが、役立ちます。
この文脈で、J.B。Rainsbergerは、単体テストの作成に苦労している場合、設計に問題を引き起こしている可能性が高いと指摘しているため、テストは設計を暗黙的に批判しています。彼は、これは良いことだと考えています。小さなテストがないと、アーキテクチャを適切に保つことができず、統合されたテストではキャプチャされない、優れた設計パターンから簡単に外れるからです。
更新：Rainsbergerが以下に指摘するように、彼はマイクロテストを単体テストと同義にすることを意図していませんでした。彼はまた、彼が通信していたことを正確に理解するのに役立つ詳細な回答も提供しています。
非常に短いバージョン：より小さなテストは、システムのより小さな部分を実行するため、プログラマーが記述できるものを自然に制約し、これにより、より鋭敏な（気づきやすい/無視しにくい）フィードバックの機会が生まれます。これは必ずしもより良い設計につながるとは限らず、むしろ設計のリスクに早く気づく機会を生み出すと付け加えておきます。
まず、明確にするために、「マイクロテスト」と言うとき、「小さなテスト」だけを意味します。 「ユニットテスト」を意味するのではないため、この用語を使用します。「ユニット」を構成するものについての議論に巻き込まれたくありません。私は気にしません（少なくともここ/今は）。おそらく2人は「小さい」の方が「ユニット」よりも簡単に同意するでしょう。そのため、この考えの新たな標準用語として「マイクロテスト」を徐々に採用することにしました。
より大きなテスト、つまり「アクション」の部分でシステムのより大きな部分を実行するテストは、より小さなテストほど明確に、または完全にデザインを批判する傾向はありません。特定のテストグループに合格できるすべてのコードベースのセットを想像してください。つまり、コードを再編成しても、それらのテストに合格します。より大きなテストの場合、このセットはより大きくなります。小さなテストの場合、このセットは小さくなります。別の言い方をすると、テストが小さいほど設計の制約が大きくなるため、少数の設計で合格することができます。このように、マイクロテストは設計をより批判することができます。
「もっと厳しい」と言って、聞きたくないけれど直接聞く必要があることを直接伝え、他の人が快適に感じられないような緊急性を伝えようと叫ぶ友人のイメージを呼び起こすやっている。一方、統合テストでは、問題に対処する時間もエネルギーもなくなった場合にのみ、静かに問題のヒントを提供します。統合テストでは、ラグの下で設計の問題を簡単に解決することができます。
大きなテスト（統合テストなど）を使用すると、プログラマーはだらしなくトラブルに陥る傾向があります。つまり、テストに合格する絡み合ったコードを書く十分な自由がありますが、次のタスクに進むとすぐに、そのコードに対する理解が失われます。 、および他の人は、もつれたデザインを読むのが不当に困難です。ここに、統合テストに依存するリスクがあります。マイクロテストのような小規模なテストでは、プログラマーは仕様の過剰によりトラブルに陥る傾向があります。通常、前のテストからのコピー/貼り付けにより、無関係な詳細を追加することでテストを過剰に制約し、比較的迅速に自分自身をペイントします。コーナーに。良いニュース：余計な詳細を書いてから数時間または数日後にテストから無関係の詳細を削除する方が、作成した数か月から数年後にもつれた本番コードを分解するよりもはるかに簡単で安全だと思います。間違いが発生するにつれて、過剰な指定はより明白な損傷をより早く行うようになり、アラートプログラマーは、修正する必要があることを以前に認識します。私はこれを強みと考えています。問題を早期に発見し、機能を追加する能力を絞める前に修正します。
彼は、優れたソフトウェア設計は、統合テストよりも単体テストのほうが優れていることを意味しています。
これが理由です。単体テストを作成すると、単体テスト可能なコードを作成する必要があります。単体テスト可能なコードは、単体テストがないコードよりも優れた設計になる傾向があります。
統合テストは同じ方法でコードに通知しません。ソフトウェアを接続する内部インターフェイスではなく、ソフトウェアの外部層をテストするだけだからです。