私は、長年C ++開発者であり、WPF開発のエキサイティングな世界で始めたばかりです。
もちろん、豊富なユーザーインターフェイスを使用してアプリケーションをテストすることは、常に困難でした。これを悪化させる問題の1つは、従来、ほとんどのWindowsアプリで、UI、UIロジック、およびアプリロジックがすべて完全に相互依存しており、個別にテストできないことでした。
私はMVVMアプローチに非常に惹かれています。これにより、UIをアプリケーションから分離し、ビューモデルで大量の自動テストを実行できます。その下にすべてのロジックがあり、ビューはかなり馬鹿げたクライアントです。ビューモデル。
これはすべてうまくいっていて、アプリケーションロジックのテストをアプリケーションUIからきちんと分離しています。ただし、UI自体を実際にテストするためのソリューションは提供されません。ビューには通常、ロジックがほとんど含まれていませんが、さまざまな種類のバグが大量に含まれている可能性があります。
ビュー自体をテストする際の現在の最先端技術は何ですか？
ありがとうトム
これは常に両刃の剣です。私はそれが低いぶら下がっている果物をつかんでそこから構築しようとしていると見ています。
理論的には、MVVMの純粋主義者は、ビューのコードビハインドにはロジックがまったく存在しないと述べています。たとえば、Prismを利用すると、これだけでなく、他のさまざまなフレームワークを軽減するのに役立ちます。したがって、この角度から見ると、ビューにロジックが存在しないポイントに到達し始めます...十分に公平です。次に、バインディングのテストを開始しますか？ただし、アプリのサイズに応じて、その投資の見返りはどのくらいになるでしょうか。
つまり、どこに線を引くのかということです。たとえば、ビューをテストしている場合でも、コードにフックしている可能性が高く、その時点でホワイトボックステストを行っています。次に、内部フックなしのテストのみが有効であるというブラックボックスの角度について議論することができます。あなたはそれが円形の悪夢になるのを見ることができます。
一般的に、私は高額商品に焦点を合わせ、そこから行き、割り当てられた時間で何が可能かをテストしました。
このように考えてください...UIを使用すると、配置などとともに、すべてのボタンの色をテストするというこの大失敗を始めることができます...それは私にはばかげています。Model、ViewModel、レイヤーでUIテストの大部分を自動化し、必要に応じてビューのバインディングをテストします。それ以外の場合は、すべてのUI開発者がワークステーションで行う必要のあるアドホックな手動作業を提案します。
WPFとMVVMは、アプリケーションのUIをテストするプロセスを変更しません。UIテスト中に通常見つけて修正するものの多くが、ビューモデルテスト中に検出されて修正されるため、これにより、検出する欠陥の数が大幅に減少します。