2

我已经对自己的项目进行了一段时间的单元测试，并希望获得有关何时停止测试的反馈。考虑以下示例。

public class Foo
{
    public object Bibble { get; private set; }

    public string Hooch { get; private set; }

    public string BibbleHooch { get { return string.Format("{0},{1}", Bibble, Hooch); } }

    public Foo(object bibble, string hooch)
    {
        if (bibble == null) 
            throw new ArgumentNullException("bibble");

        if (string.IsNullOrEmpty(hooch)) 
            throw new ArgumentNullException("hooch");

        Bibble = bibble;
        Hooch = hooch;
    }
}

这些是我在调用构造函数时能想到的以下测试。

  • 一个空圣经抛出
  • 一个空的钩子抛出
  • 一个空的钩子抛出
  • 一个有效的圣经但空的 hooch 抛出
  • 一个空的圣经，但有效的方式抛出
  • bibble 和 hooch 都设置为 null throws
  • 一个有效的圣经和 hooch 不要扔
  • 有效的 bibble 和 hooch 意味着 Bibble 和 Hooch 不应为空
  • 有效的 bibble 和 hooch 意味着 BibbleHooch 不应为空
  • 一个 hooch x 应该与 Foo.Hooch 相同
  • a bibble y 应该与 Foo.Bibble 相同
  • x 的 hooch 和 y 的 bibble 意味着 Foo.BibbleHooch 应该与 xy 相同

鉴于这些是不同的排列，我会说它们都是有效的场景。当然可以删除一些重复，但事实仍然是需要大量测试来涵盖构造函数的创建。如果我有 SetBibble() / SetHooch 方法，我就会陷入严重的重复。

我的问题是：你会测试以上多少，你如何处理排列的测试，编写测试的成本何时超过测试的价值。

4

2 回答 2

2

我会测试实际的逻辑，而不是因为测试 getter 和 setter 而忘乎所以。通常在测试对象之间的交互过程中会涉及到 getter 和 setter。在您的示例中，我认为可能需要测试的唯一事情是抛出 IllegalArgumentExceptions，并且格式化有效。（考虑到您的属性允许成员重置为 null，测试是否抛出异常并没有太大价值。）

单元测试应该主要对开发人员有用，它们不是为了让管理人员满意或满足代码覆盖率指标（尽管有很多地方被这种事情冲昏了头脑）。我不会花时间测试不相关的事物的不同组合。

于 2013-04-17T15:03:31.783 回答
2

为什么要测试不相关参数之间的交互？您在问题中命名了许多重复的测试。如我所见，您有：

空测试

  • ArgumentNullException测试空圣经
  • ArgumentNullException测试空 hooch
  • ArgumentNullException空钩测试

属性测试

  • Bibble由ctor正确设置的属性
  • Hooch由ctor正确设置的属性
  • BibbleHooch属性返回期望值

这 6 个测试完全涵盖了课堂上所有可能的场景。

如果我有 SetBibble() / SetHooch 方法，我就会陷入严重的重复。

如果没有必要，不要暴露 setter。更喜欢你的类的最小接口——你需要更少的测试并且逻辑会更简单。

于 2013-04-17T15:11:38.010 回答