unit-testing - MVPは常に価値がありますか？

Question

MVPは*すべての*GWTアプリケーションのベストプラクティスと見なされますか？

• 小さな社内Webアプリケーションについてはどうでしょうか。
• そのようなアプリケーションや他のアプリケーションに 単体テストを使用しないのは間違いですか？
• 単体テストが行​​われないアプリケーションの場合、MVPを使用したい他の理由はありますか？

Answer 1

1. 一般に、MVPはGWTアプリケーションを開発するためのベストプラクティスと見なされています。パターンを適用するいくつかの理由は、このGoogle I/Oプレゼンテーションにあります。
2. MVPには代償が伴い、アプリケーションにさらにいくつかのクラスと複雑さが導入されます。ただし、結合を最小限に抑え、アプリケーションをよりテストしやすくします。したがって、パターンが苦痛に値するかどうかを判断するのは、設計者としてのあなた次第です。
3. エクストリームプログラミングのようないくつかの方法論は、ソフトウェア開発プロセスに自動テストを含めることを奨励しています。繰り返しになりますが、テストを含めるには、チームがより多くのコードを作成する必要がありますが、その代わりに、コードは堅牢で信頼できるものになります。アプリケーションが小さい場合でも、単体テストを含めることを強くお勧めします。
4. 前に述べたように、簡単なテストはMVPの利点の1つですが、それだけが利点ではありません。グーグルからのこの記事によると：

MVPは、複数の開発者が同時に作業できるように開発を切り離します

Answer 2

まあそれは主観的です、デザインのものは常にトレードオフです。

小さなアプリの範囲/サイズ/将来についても議論の余地がありますが、私たちは通常、複雑さを軽減したり、キヤノンでハエを殺したりしないように、小さなアプリのことをシンプルに保ちます

ただし、チームがすでにMVPに慣れている場合は、MVPを使用することを強くお勧めします。これは、サイズが大きくなるにつれて、パターンがスパゲッティコードを回避するのに役立つためです。

Answer 3

MVPを使用しないことは、必ずしもテストできないことを意味するわけではありません。自動テストツールを使用してUIからいつでもアプリをテストできますが、それらは作成が難しく、壊れやすくなっています。アプリケーションが複雑な場合、またはアプリケーションを保守する必要がある場合は、ユニットをテスト可能にすることで長期的に見合うことができます。

Answer 4

MVPパラダイムにはメリットがありますが、私自身は、モデルとGWT固有のビュークラスの間に追加のプレゼンテーション層を持たないことを好みます。すべてのビジネスルールをビュークラス（UIBinderのもの）から厳密に除外し、代わりにモデルクラスに配置するようにします。

同様に、私はすべてのGWT.create(..)ものをモデルから除外します。これにより、サーバー側のモデルクラスに手間をかけずにアクセスできます。次に、RPC呼び出しのJUnitテストでSyncProxyを頻繁に使用します。

最終的に、リッチWebクライアントを作成する場合、特にさまざまなプラットフォーム（ブラウザーなど）用に生成されたコードによってレンダリングされる場合は特に、ビューの自動テストにあまり依存することはできません。プリンの証拠は、Internet Explorer、Firefox、Chromeがそれを作っていることにあります。