Question

我正在为类编写测试方法

例如：

class employee{

   public int ButtonID
        {
            get
            {
                return 
                function(GetValue("ButtonID"), 0);
            }
            set
            {
                SetValue("ButtonID", value);
            }
        }

    public function getEmployeeID()
    {somthing; }

    private function setEmployeeID()
    {somthing; }

    protected button_click(e)
    { somthing; }

}

在我们计算代码覆盖率时，它还包括

getter and setter methods
按钮点击事件。
公共职能
私人职能

我是否应该看到以上四种情况的报道？

Answer 1

特定于第1点和第2点：

测试getter和setter取决于那些访问器方法正在做什么。如果它们是自动实现的，那么我不建议明确地测试它们。我相信.NET Framework的实现。如果您正在寻找更多的代码覆盖率，请确保在其他测试期间get和set属性，并且将计算覆盖率。

如果在属性访问器中发生了更复杂的事情，那么使用单元测试来帮助创建它（如果遵循测试优先TDD）或确保逻辑正确实现可能是有用的。

当谈到特定于UI的代码时，不值得尝试使用单元测试来测试它。试图在单元测试中操纵UI会导致片状，慢速测试。如果要在按钮单击处理程序中测试某些内容，请尝试将该功能提取到另一个可以更容易进行单元测试的类中。保持代码隐藏文件尽可能薄 - 将工作委托给您可以测试的其他类。

关于第3点和第4点：

正如评论者指出的那样，公共方法为创建单元测试提供了丰富的目标区域。您希望确保您的类的公共API按预期执行，并且测试公共方法使您有机会了解使用被测试类的容易程度。如果在测试中使用某些东西很尴尬，则可能表明需要进行设计更改。

仅通过公共方法测试您的私有方法。单元测试应该测试你的类的行为，而不是实现。从理论上讲，你应该能够通过公共方法锻炼你的私人方法。

单元测试代码覆盖范围应包括哪些内容？

1 个答案: