VIPERアーキテクチャーでの単体テスト：可能ですか？
TL; DR VIPERには値を返すメソッドがないので、どのようにテストするのですか？
理由：
VIPERでは、各層は、その層への抽象的な参照（プロトコル/インターフェース）を保持することにより、他の層と通信しています。
たとえば、ビューにはプレゼンターへの参照があります。ビューがpresenter.getSomething（）を呼び出す場合、プレゼンターはすぐに値を返しません。代わりに、プレゼンターはビューの参照を持ち、その操作の完了後、プレゼンターはview.setSomething（something）を呼び出します。
このフローは、レイヤー間のすべてのフローで一貫しています。言い換えると、これらのプロトコル/インターフェースを実装するクラスは、プロトコルおよびインターフェースから実装するメソッドのみを公開します。テストの作成中は、これらのパブリックメソッドにのみアクセスでき、これらのメソッドはすべてnullを返します。
値を返すことができる引数は、呼び出し後に実行される操作が非同期でなければならない実際のケースでは十分に有効ではないため、呼び出し時に値を直接返すのではなく、VIPERのようなコールバック構造を使用する必要があります。
まだ、VIPERを説明するすべてのブログ投稿、記事、およびビデオは、TDDでコードをテスト可能にすることを主張しています。
編集：質問があります ユニットテストvoidメソッド これはこれの複製のように見えるかもしれませんが、私の質問は同様の動作について、それをテストする方法ではなく、アーキテクチャがアプローチを制限する方法について（少なくとも私の理解に対して）。
ああ、それは可能です。それはあなたがそれがどのように見えるようにしたいのかだけではありません。
あなたが不満を言っているのは、出力ポートの使用です1 、 2 、 結果を返すのではなく、結果を伝えるため。これはテストをより複雑にしますか？はい。では、なぜそれを行うのでしょうか。それはあなたに多態性の別の層を与えるからです。
return の場合、呼び出し元に戻ります。あなたは選択肢がありません。他に行くところはありません。つまり、呼び出し元は結果の処理方法を知っている必要があります。あなたが出力ポートを持っているなら、あなたはあなたを聞く方法を知っているどんな人にも結果を送ることができます。それは強力です。
なぜそれが強力なのですか？あなたはいつも前進しているからです。常に抽象化に向かっています。背後に忍び寄るのではなく、本来の使用方法で物事を使用する。抽象化は、それらをハッキングしていない場合にうまく機能します。
これをテストするには、出力ポートをリッスンする方法を知っているものを設計する方法を知る必要があります。しかし、とにかくそうするつもりでした。だから問題は何ですか？
問題は、非常に多くの人々が構造的に考えることに巻き込まれることです。 「私がしているのは、メソッドが呼び出されたことをテストすることだけです。」いいえ。結果を伝えるメッセージが送信されたことをテストしています。このミニ出力ポート言語で、それがメソッド呼び出しのように見える場合は問題ありません。 「しかし、これは実装の詳細です！」いいえ、それは出力ポート言語の一部です。そのメッセージで何をするかは彼ら次第です。それで行われるのは実装の詳細です。
「しかし、テストするのはとても大変です！」ええ、そうです。しかし、あなたがそれを使うことに決めたので、それはあなた自身の責任です。 「それで私はそれを使うべきではないのですか？」いいえ、何か役立つことをしたとき、それを理解したとき、そしてそれが引き起こす痛みに値すると思ったときに使用する必要があります。