测试气味....这是一个好习惯吗？

我有两个测试，它们是完全一样的......除非两件事情，他们叫两个独立的服务电话..因此，当使用即时通讯的Mockito我有两个不同的预期和验证线...测试气味....这是一个好习惯吗？

这是我这样做：

@test 
TestA { 
    baseTest("player"); 
} 

@test 
TestB { 
    baseTest("member"); 

} 

BaseTest(type type) { 
    .... 
    ..... 
    if type(player) { 
    Mockito.when(player service call) 
    } 
    else { 
    Mockito.when(member service call) 
    } 

    // make the call in code 

    //verify 

    if(player) { 
    verify player specific service call... 
    } 
    else { 

    } 
}

我觉得上面的是一个测试的气味......只是不觉得不对劲......

是否有更好的方法，然后将If语句在我绷测试？

来源

2012-09-20 user1555190

@maba，我开始同意你的看法，但这个用户很新。抱抱他会回来的希望。 – TecBrat

@TecBrat我知道我们不应该评论人的AR，但在这种情况下，我无法抗拒... – maba

@maba我再问一次什么是AR？... MFA !! – user1555190

您应该独立开发测试代码，并在他们有意义。

举例说明。初始化代码的一条经验法则（排列/行为/断言的第一个A）是：

您应该在测试中写入测试方法的所有Arrange部分。
如果您的方法与所有其他方法共享初始化，然后将其置于@Setup方法
如果某些测试方法不共享该初始化，可能是因为它不适合该测试用例。

所以我的结论是：

写独立测试
如果他们共享的东西，你可以重构
但不会太大（或类似的“如果”是个奇怪的事情）！！增加复杂性，而不是重复使用。

实际上@artbristol的答案是有意义的：如果你使用if来替代行为考虑多态性。这只是我不确定，直到哪一点对测试来说都很复杂（如果代码正在测试类似的类层次结构，则可能是有意义的）。

来源

2012-09-20 12:48:30 helios

我仍然只是单独实施2个测试类。代码长度和重复对于测试并不重要，代码可读性，完整性和正确性优先。有鉴于此，只需分别实施2个测试用例。

来源

2012-09-20 12:43:11 Minion91

代码长度和重复在测试中很重要。如果你能重构掉重复的测试功能，你绝对应该这样做。维护更少的代码总是更容易。我赞赏OP试图减少测试代码的数量，即使它们没有以最好的方式做到这一点。请参阅@ artbristol的回答，以获取最佳方式的意见。 –

任何你看到重复如果这样的陈述，你可以使用多态。您应该在超级BaseTestSuper中提供“玩家服务调用”和“会员服务调用”方法，该超级方法也将拥有现有的BaseTest方法。

来源

2012-09-20 12:45:04 artbristol

+1为多态性建议。我不确定在测试中使用它，但它非常有趣。 – helios

一般而言，您不应该为测试增加任何复杂性。首先，你可以在那里犯错（即使在简单的情况下）。其次，您的测试不再是一个文档，这意味着您无法轻松理解测试类的使用情况和行为。

所以这是一种气味。 :)

来源

2012-09-20 19:05:22

测试气味....这是一个好习惯吗？

回答

相关问题