その話の私の解釈は：
- クラスではなくテストコンポーネント。
- インターフェイスポートを介してコンポーネントをテストします。
講演では述べられていませんが、アドバイスの想定されるコンテキストは次のようなものだと思います。
- たとえば、ユーティリティライブラリやフレームワークではなく、ユーザー向けのシステムを開発しています。
- テストの目標は、競争力のある予算内で可能な限り成功することです。
- コンポーネントは、C＃/ Javaのような単一の成熟した、おそらく静的に型付けされた言語で記述されます。
- コンポーネントは10000〜50000行のオーダーです。MavenまたはVSプロジェクト、OSGIプラグインなど
- コンポーネントは、単一の開発者または密接に統合されたチームによって作成されます。
- あなたは六角形のアーキテクチャのようなものの用語とアプローチに従っています
- コンポーネントポートは、ローカル言語を残す場所であり、そのタイプシステムは、http / SQL / XML / bytes / ...に切り替えます。
- すべてのポートをラップすることは、Java / C＃の意味での型付きインターフェースであり、実装をスイッチテクノロジーに切り替えることができます。
したがって、コンポーネントのテストは可能な限り最大の範囲であり、その範囲内で何かを単体テストと呼ぶことができます。これは、一部の人々、特に学者がこの用語を使用する方法とはかなり異なります。典型的な単体テストツールチュートリアルの例とはまったく異なります。ただし、ハードウェアテストの起源と一致しています。ボードとモジュールは単体でテストされており、ワイヤとネジではありません。または、少なくとも、ネジをテストするための模擬ボーイングを構築しないでください...
それから外挿して、私自身の考えをいくつか入れて、
- すべてのインターフェイスは、入力、出力、または共同作業者（データベースなど）になります。
- 入力インターフェイスをテストします。メソッドを呼び出し、戻り値をアサートします。
- 出力インターフェイスをモックします。所定のテストケースで予想されるメソッドが呼び出されることを確認します。
- あなたは協力者を偽造します。シンプルだが機能する実装を提供する
それを適切かつきれいに行えば、モックツールはほとんど必要ありません。システムごとに数回しか使用されません。
通常、データベースは共同編集者であるため、偽造されるのではなく偽造されます。これを手作業で実装するのは苦痛です。幸いなことに、そのようなものはすでに存在しています。
基本的なテストパターンは、一連の操作を実行することです（たとえば、ドキュメントの保存と再読み込み）。動作確認します。これは、他のテストシナリオと同じです。そのようなテストが失敗する原因となる可能性がある（動作中の）実装の変更はありません。
例外は、データベースレコードが書き込まれますが、テスト中のシステムによって読み取られないことです。たとえば、監査ログなど。これらは出力であるため、モックする必要があります。テストパターンは、一連の操作を行います。指定されたメソッドと引数を使用して、監査インターフェイスが呼び出されたことを確認します。
ここでも、mockitoなどのタイプセーフなモッキングツールを使用している場合、インターフェイスメソッドの名前を変更してもテストエラーは発生しません。ロードされたテストでIDEを使用する場合、メソッドの名前変更とともにリファクタリングされます。しないと、テストはコンパイルされません。