1

如题。

我有一个实现需要排序的 IComparable 的类。我针对所有方法编写了所有单元测试。但是，编写一个单元测试来检查它是否实现了 IComparable 是否有意义？

因为在 UI 中排序时使用界面将无法正常工作。但是编译它仍然可以工作。因此，如果我有这样的测试用例，如果有人删除了该接口，它就会被捕获。

我的课是这样的：

 public class ComparableCustomType: IComparable
    {
        private readonly someFields;

        public ComparableCustomType(AnotherBusinessObject obj)
        {
              //Do some parsing against the obj
        }

        public int CompareTo(object obj)
        {
             //Some custom sorting logic
        }
    }

基本上我的测试用例将是：

[TestMethod]
public void CompareTo_IsImplementIComaparable()
{
      IComparable comparable = Isolate.Fake.Instance<ComparableCustomType>();
      Assert.AreNotEqual(null, comparable);    
}

编辑：这就是我使用这个属性的方式......（或者我应该说这就是这个人使用这个属性的方式......）

public class CustomItem{

    private AnotherBusinessObject anotherBusinessObj = null

    public CustomItem(AnotherBusinessObject obj)
    {
        this.anotherBusinessObj = obj;
    }

    public ComparableCustomType {
        get { return new CamparableCustomType(this.anotherBusinessObj); }
    }

    public string SomeOtherProperty {get;set;}

    publci int AnotherProperty {get;set;}

}

public ObservableCollection<CustomItem> MyCustomCollection {get;set;}

然后这个集合将数据绑定到我的 GridView ......所以它会自动生成所有列......

4

2 回答 2

5

我想说不要测试编译器会为你捕获的任何东西。由于您遇到编译器无法捕获的情况，因此为其创建 UT 似乎是合法的。

于 2012-04-26T20:44:13.880 回答
5

为了快速总结我的答案，我说不，编写单元测试来检查类实现/继承的内容没有多大意义。IMO，应该编写单元测试来测试逻辑/功能，而不是类型。这很像编写测试以确保您可以实例化构造函数。通常这样的事情是矫枉过正的，我相信这种情况也是矫枉过正的。

应在编译时检查您的代码。您可以在实例化对象时应用此约束（如果这对于您使用对象的方式是可能的）。

假设您的实现类IComparable被称为FooComparable：

IComparable foo = new FooComparable();

同样，如果您已经实例化了对象并且它的唯一功能不一定是IComparable对象，您可以应用几个其他约束。假设你有你的FooComparable并且你想确保它IComparable在绑定到控件之前，你可以做这样的事情：

IComparable dataSource = fooObj;

如果你尝试这个并且 FooComparable 没有实现 IComparable，编译器会抱怨。也许您应该提供一个代码示例来说明您如何使用该类，以便我们提供更多建议。

于 2012-04-26T20:49:56.000 回答