这不仅仅是一个实际案例,在试图获得单元测试和集成测试之间的细节差异时,这是一个问题。这是集成测试还是单元测试?
可以说我有一流的总和,它增加了两个整数:
class Sum{
int x;
int y;
public int add(){
return x + y;
}
...getters and setters...
}
而且我还有一个类,负责验证结果,以确认值的预期。只是为了举例来说,假设我们要添加唯一的正数:
class ValidateSum{
Sum sum;
public boolean validate(){
if(sum.getX()>=0 and sum.getY()>=0){
return true;
}
else{
return false;
}
}
... getters and setters...
}
也许它没有很多的意义有ValidateSum,还是让我们只是假设它为例子的缘故。
现在我想为ValidateSum编写测试。如果我这样做:
@Test
public void testValidateSum(){
ValidateSum vs = new ValidateSum();
Sum sum = new Sum();
vs.setSum(sum);
boolean result = vs.validate();
assertTrue(result);
}
是单元测试还是集成测试?
我知道单元测试只需要验证ValidateSum中的功能,并且以测试的方式进行:它只从Sum获取属性,而不是它的任何功能。
但是另一方面,即使ValidateSum只调用getter,也可以说您正在从Sum访问功能。 Sum的getter中的任何更改都会影响ValidateSum的测试,从而打破了单元测试的概念。
但是如果是这种情况,并且确实是一个集成测试,那么我该如何为ValudateMethod的validate()写一个单元测试?
我无法想到的唯一事情就是嘲笑Sum,所以它会返回相同的值。即使Sum的getter中的逻辑发生了变化,ValidateSum的测试也会保持不变。问题在于嘲笑getter的响应可能会增加不必要的复杂性,因为getter中的逻辑更改的可能性非常低,而我们所做的只是获得一个属性。
我希望我的问题有意义,这更多的是理论上的疑问。
编辑
谢谢您的解答。他们有重要的事情要记住。我选为最佳答案之一,就是因为它使我这个:
http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html
而其真正的:理论上我会嘲笑总和,使其成为一个纯粹的单元测试。但是对于大多数情况,添加复杂性的成本以及花费在模拟属性getter上的努力并不值得仅仅是为了获得“最纯粹的”单元测试,实践中,对于这种情况,Unit和Integration测试之间的差异是主观的。
这是一个单元测试,但ValidateSum与Sum紧密结合。如果一个变化(如Sum),那么你也必须改变'ValidateSum'。事实上,'ValidateSum'应该可能是你的jUnit类中的一个函数。 –