3

コード行が 2 回目に削除された箇所を修正する必要がありました。そこで、そのためだけに単体テストを作成することにしました。

コンストラクター内のクラスは、テストするプロパティを設定します。このプロパティはたまたま保護されているため、単体テストでアクセスできません。

 [Test]
 public void Constructor_WhenCalled_ThenSomePropertyIsPopulated()
 {
     var vm= new SomeViewModel();
     //line below doesn't compile as SomeProperty is protected
     Assert.IsNotNull(vm.SomeProperty);

そこで、単体テスト ファイルで、そのクラスを拡張し (シールされていませんでした)、保護されたプロパティをパブリック ゲッターとして公開することにしました。

public class SomeViewModelExtended : SomeViewModel
{
    public SomeViewModelExtended() : base() { }

    public new object SomeProperty
    {
        get { return base.SomeProperty; }
    }
}

 //now I can test
 [Test]
 public void Constructor_WhenCalled_ThenSomePropertyIsPopulated()
 {
     var vm= new SomeViewModelExtended();
     Assert.IsNotNull(vm.SomeProperty);

現在、私のチームには、特にパブリック インターフェイスのみをテストするべきであり、これは完全に手っ取り早く汚いハックであるという議論があります。

しかし、単体テストの目的の 1 つは、不要な変更からコード ベースを保護することではありませんか? これが完全に間違っている場合、他に何をすべきですか？

4

3 に答える 3

2

Roy Osherove の 'Art of Unit Testing' を読んだ後、これに関する私の意見は、テストと保守性が優れたコードの主要なユース ケースであるということです。そのため、テストを支援するために型を拡張することは十分に有効であると私は感じています。

もちろん、それを必要としない型を設計できるのであればそれは良いことですが、保守性とテスト容易性が最も重要です。

漏れやすい抽象化は悪い選択だとよく言われますが、ほとんどの場合、これら 2 つの主要なユース ケースが考慮されていないことが原因であることがわかりました。抽象化は、機能、テスト、メンテナンスなど、すべてのユーザーに適している必要があります。

于 2013-06-07T19:37:08.187 に答える