2011-12-01 27 views
0

我遇到了很多在单元测试期间使用/不使用多重断言的资源。但是,在编写UI级别的自动化集成测试时,我最终在一次测试中做了很多断言,这对我来说似乎不是什么坏主意,尤其是当我使用软断言时,只会在拆解期间失败并报告测试方法中的所有断言失败而不是将其限制为每个测试一个报告。通过集成测试引发理智的多重断言

一个这样的场景是填写一个有10个字段(文本框,下拉等)的表单。回到表格并验证所有输入的值是可用的。我不喜欢我的测试,它充满了许多断言。我想断言所有这些值,但仍然希望我的测试,看起来很干净,不喜欢 -

public void testMethod() { 
    // Some operation here 
    softAssert("verification failed for field 1, expected value:" +value, isValuePresent(value)); 
    softAssert("verification failed for field 2, expected value:" +value, isValuePresent(value)); 
    softAssert("verification failed for field 3, expected value:" +value, isValuePresent(value)); 
    // Some more assertions here 
} 

我可以提取这些断言,以不同的方法,但后来我觉得断言应保存在试验方法。明确测试方法中正在测试的内容。

只是一个微不足道的感觉,我有这样的测试设计是合理的吗?或者 我可以在我的测试方法中进行设计增强。

回答

3

你可以做我所谓的“通过实例断言”,这只是表单级别的断言。它看起来像这样:

public void testMethod() { 
    Form expected = new Form() 
        .field1('value1') 
        .field2('value2') 
        .field3('value3') 
        .field4('value4') 

    Form result = someFormOperation(); 

    softAssert(expected, result); 

} 
1

我经常在某些结果和assertEquals上调用toString()来获得正确的结果。如果你的底层对象实现了合理的toString(或者toXML等),那简化了测试代码。但对未来的变化不太健壮。

+0

我认为它实际上会更好地打破未来的变化,所以更可能的是测试会更新。 –