单元测试c#属性

soc*_*rix 9 .net c# tdd xunit

我正在使用一个有很多属性的类.例如;

public class Bib
{        
    public int PartQty { get; set; }
}
Run Code Online (Sandbox Code Playgroud)

现在进行单元测试; 我做了xUnit测试

    [Fact]
    public void CanGetAndSetPartQuantity()
    {
        const int expected = 3;

        var target = new Bib() {PartQty = expected};

        Assert.Equal(expected, target.PartQty);
    }
Run Code Online (Sandbox Code Playgroud)

在这里,我讨厌我的硬编码预期= 3.有什么方法可以测试访问器和mutator的这个属性?

Rob*_*t P 14

由于此属性除了作为整数的getter/setter之外没有任何行为,因此您基本上只是测试编译器的工作原理.这基本上没有为您的测试增加任何价值.考虑完全删除它.这可以减轻你这种奇怪的情况.:)

如果你确实有一些你想要捕获的行为(例如,允许的边界条件),你只需要测试那些,而实际上没有别的.通常,您将拥有作为对象一部分可用的边界条件的常量.考虑使用这些常量,+/ - 一些适当的增量.

  • 我不能同意这一点.如果我们谈论TDD,则无法保证可写属性有效.关于"仅测试编译器工作"的论点推断测试知道SUT的内部实现.情况并非如此. (9认同)

Mar*_*ann 8

约束非确定性非常适合这种单元测试.写它像这样:

[Fact]
public void CanGetAndSetPartQuantity()
{
    const int expected = new Random().Next();

    var target = new Bib() {PartQty = expected};

    Assert.Equal(expected, target.PartQty);
}
Run Code Online (Sandbox Code Playgroud)

无论输入是什么,这都可确保输出正确表示输入.


Dan*_*ant 6

我坚信单元测试是'白盒'测试,这意味着你可以使用已知的角落情况来选择你的测试输入.在这种具有自动属性的特殊情况下,如果您信任编译器,则不需要进行测试.如果您不能相信编译器以您期望的方式实现自动属性,那么您也不能相信它可以像您所写的那样执行测试.

也就是说,如果你有一个更复杂的setter,你可以根据可能的失败案例选择你的输入.一些典型案例:

  • 验证> = 0的属性的负数
  • 其他验证失败
  • 像Int.MaxValue这样的极端边界情况有时会触发setter中的溢出和意外行为
  • 一个应该通过验证的任意值(没有关于如何在这里选择值的实际指导,只要你知道它在'好'的情况下.)