0

多くの開発者が同じ Asp.net MVC アプリケーションで作業しているプロジェクトがあるとします。プロジェクトは長期的なものであるため、チームメンバーは時間とともに変化します。これは、この期間中に、特定のビューが他のビューと (完全に) 異なるように見えるポイントに到達することを意味します。賢明なマークアップ。

UI の一貫性を可能な限り維持するために、最初のチームが汎用的なビュー構造を作成するための流暢な Html ヘルパー メソッドを開発したとします。すなわち:

Html.CreateHeader("Header text")
    .CreateForm(Url.Action(...))
    .AddSegment("Person")
    .EditorFor(model => model.Person)
    .AddSegment("...")
    .EditorFor(model => model.Company)
    ...

これにより、日常の Asp.net MVC ビュー コードに抽象化が追加されますが、時間の経過とともにビューの一貫性が保たれます。もちろん、これらの流暢なヘルパーが使用される場合。

しかし。これらのヘルパー メソッドはそれぞれユニット テストできますが、ビュー自体をテストするのにどのような利点があるのでしょうか。

質問

  1. 私の意見では、静的なもの (つまり、ビュー) を単体テストしないでください。したがって、ビューに豊富なクライアント側機能がない限り、何もテストする必要はありません。しかし、もしそうなら、ie で Javascript コードをテストすることになります。QUnit ライブラリ。この考え方は正しいのでしょうか、それとも本質的に静的なものをテストすることは本当に意味があり、特定の要素とそのコンテンツの存在のみをテストすることになるのでしょうか?

  2. ビューの他のどの側面をテストできますか? また、なぜそれらをテストする必要があるのですか?

開発中に、単体テストは重要なコードに対してのみ実行する必要があることに気付きました。言い換えれば、少なくとも 1 つのブランチを持つメソッドをテストする必要があり、その他のメソッドは、ブランチがなくても何をするのか完全には明らかではないほど長いものをテストする必要があります。

私は本質的に些細なメソッドの単体テストを書くことを避ける傾向があります。それらは開発者の時間を消費する以外には何の助けにもならないからです。

4

1 に答える 1

2

ビューは、提供されたデータのみを表示する必要があるため、テストするロジックはありません。

私の意見では、ビューの「テスト」は統合テストの下にあります。(すべてが正常に見えるか、リンクが適切な場所に移動するかなどを確認します)

于 2012-05-03T10:48:55.357 に答える