Question

我是单元测试的初学者，我遇到了一些我不知道如何解决的失败。我试图测试我的简单类Employee，其中我有创建对象的静态计数器，因此新员工可以获得连续数字和默认名称，如“Name1”，“Name2”等。这是我的默认初始化块：

companiesData$Margin<-apply(companiesData,1,function(x){(x[4]/x[3])*100})

我用一些方法编写了一个JUnit类。它们工作得很好但是有关计数器的方法只有在我单独运行它们时它们才起作用（当我将它们保存为单独的测试时它们也工作，但是有这么多文件看起来很麻烦）。当我使用所有测试方法运行类时，计数器正在添加更多对象，我不知道为什么/何时/何时作为测试是独立的。在测试方法中，我正在创建一个对象并使用assertEqual检查计数器。寻找解决方案我尝试使用@ Before，@ After等，但它是相同的或者我可能不知道如何正确使用它。我的问题是我可以做些什么来让所有测试方法工作或者我应该在@Before方法中写什么（我尝试添加和删除对象到ArrayList和/或设置为null）。我想只有在单独运行时才能进行测试是不可接受的。任何帮助将不胜感激。谢谢！

Answer 1

不要使用静态字段作为员工的柜台。请改用实例字段：

public class Manager {
    private int employeesCount;

    public Employee addEmployee() {
        employeesCount++;
        Employee employee = new Employee();
        employee.setName("John " + employeesCount);
        employee.setLastName("Smith " + employeesCount);
        return employee;
    }
}

有许多充分的理由不使用静态字段（读取：why static variables are bad）来维护状态，其中之一就是这使得您的代码无法测试。如果你在object（在实例字段中）维护你的状态，那么实例化你的对象并按原样测试就没有问题。

相反，请确保程序中只有一个Manager实例，并且每个人都使用它（这称为单例）。嗯，有单身模式。还有许多不使用它的好理由（阅读：why singletons are bad）。因此，当你编写真正的应用程序时，你通常会使用一些依赖注入框架（如spring或guice），并且它们能够为你实例化单例当你想要它时。

嗯，这里有点幽默，但我确信你会认为全球状态被认为是不好的做法，测试它的难度是它表现出来的一种方式。

Answer 2

答案frenzykryger提供了许多有价值的见解，但还有更多内容。

您应该始终考虑SOLID的工作。在您的示例中，＆＃34;单一责任原则＆＃34;可以指导更好的解决方案。你看，好的OO编程是关于创建有用的抽象。你在员工中提出的一些抽象根本就不属于那里。

例如，可以创建一个类Employee来建模为某个公司工作的人。所以，员工是人，所以他们可能有名字;因为他们是组织的一部分，是的，他们可能有一个ID。

但是：员工获得了一个ID！当你从一家新公司开始时，人们不会上来问你：＆＃34;请告诉我们你的新数字ID＆＃34;。相反，有人来找你并告诉你＆＃34;这是你的数字身份证，不要忘了它＆＃34;。

所以，考虑到这一点，有人建议：

员工的核心属性没有 setters 。所以，像＆＃34; ID＆＃34;或＆＃34;名称＆＃34;那些意味着要更改的不应该作为参数传递给构造函数。您只是不创建员工对象，稍后允许更改该实体的名称或ID！
所以，正如另一个答案正确指出的那样：一些外部阶级，比如＆＃34;经理＆＃34;必须跟踪所有＆＃34;已知＆＃34;雇员;如果添加了新的，那么该管理器会以某种方式计算一个新的唯一ID。

最后：确实如此：静态在良好的OO设计中是异常。人们应该有充分的理由转向静态字段（可能是常量除外）和方法。静态始终会导致紧密耦合的代码 - 并且需要避免的事情！

JUnit测试对象的静态计数器

2 个答案: