通过集成测试引发理智的多个断言

时间:2011-12-01 05:52:02

标签: java unit-testing integration-testing

我遇到过许多资源,谈论在单元测试期间使用/不使用多个断言。但是在编写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
}

我可以将这些断言提取到另一种方法,但后来我觉得断言应该保存在测试方法中。明确测试方法中的测试内容。

我只有一种微不足道的愚蠢的感觉,并且这样的测试设计是合理的吗?要么 我可以在我的测试方法中进行设计增强。

2 个答案:

答案 0 :(得分:3)

你可以做我称之为“通过示例断言”的内容,这只是表单级别的断言。它看起来像这样:

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

  Form result = someFormOperation();

  softAssert(expected, result);

}

答案 1 :(得分:1)

我经常在一些结果上调用toString()并将assertEquals调用到正确的结果。如果底层对象实现了合理的toString(或toXML等),那么简化了测试代码。但它对未来的变化不那么强大。