测试用例使此代码失败？答案

【问题标题】：Test case to fail this code?测试用例使此代码失败？
【发布时间】：2009-07-31 06:52:14
【问题描述】：

我必须维护承包商的代码。它有这个“有趣”的 sn-p：

String webServicesValue = 
  webResponse.substring(webResponse.indexOf("<" + fieldName + ">") + 
                        fieldName.length() + 2, 
                        webResponse.indexOf("</" + fieldName + ">"));

我花了几分钟才明白他想做什么。

这似乎是一个 WTF 代码，但我的同事建议，“如果它没有损坏，请不要修复它。”我想知道这段代码是否会失败。到目前为止它似乎工作正常，老实说，我想不出一个测试用例会失败。

谢谢，

【问题讨论】：

我猜应该是你做加法的 fieldName.length()
“失败”如“引发异常？
你是对的。它是 fieldName.length()。
这是一个非常酷的问题。

标签： java unit-testing testing

【解决方案1】：

是的。如果响应中不存在“”，它将引发异常。具体来说，它会尝试调用 webResponse.substring(fieldName.length() + 1, -1);

"" 会导致类似的问题，元素上的任何属性也是如此。

如果你得到“ ... ... ... ”，你会得到错误的答案。

编辑：根据后续讨论，我想说应该重写此代码以使用适当的 XML 解析器...除非您/您的团队可以保证代码将永远必须处理有问题的 XML。 XML 只是允许通过临时字符串操作来处理太多有效（和无效）的变体。

【讨论】：

当然，您可能会争辩说这些输入是“不可能的”……这可能就是承包商的想法。但是，当您更改系统时，“不可能”的事情可能会开始发生。

【解决方案2】：

如果您收到 <fieldname/> 会怎样？

【讨论】：

这是一个有效的测试用例。我打算和我的同事讨论这个问题。但是，根据您的经验，Web 服务是否有可能生成此类标签？到目前为止，我只使用了一个 XML 库，它总是为空标签生成。
因为我不知道它是什么类型的网络服务，所以除了“很可能，因为它是有效的 XML”之外，我无法告诉您任何其他信息：)。但总的来说，防御性编码是明智的：因为 Web 服务对你来说是一个外部实体，你永远不知道它会返回什么样的东西。现在修复几行代码比以后修复生产中可能出现的错误要便宜得多。因此，我建议在更改此代码之前围绕此代码编写一些单元测试，然后重构代码以减少出错的可能性。并保持这些单元测试在未来运行。
@gineer：“但是，根据您的经验，Web 服务是否有可能生成此类标签？”。尝试摆弄配置选项，您可能会得到它来生成不同外观的 XML。此外，您怎么知道 XML 是由 XML 库生成的？如果您的代码是手动解析 XML，那么另一端可能是手动生成它！

【解决方案3】：

与其手动解析 XML，不如使用真正的 XML 解析器。有各种各样的极端情况很难用简单的字符串操作来覆盖。使用真正的解析器也将更具可读性。最好将 XML 数据视为二进制数据，尤其是在考虑所有可能的字符编码时。

【讨论】：

【解决方案4】：

除了上面 Igor Brejc 和 Stephen C 的回复，还有 CDATA：

<fieldname><![CDATA[ I am not really </fieldname> ]]></fieldname>

甚至

<othertag>
  <![CDATA[ I am not really <fieldname> and there is no closing tag ]]>
</othertag>

【讨论】：

查看我的评论“......并且存在您可能甚至不会考虑的理论变化”。它也适用于我:-)

【解决方案5】：

我建议在这种情况下重新编写它。如果不容易理解，那就更难测试了。

【讨论】：

+1 同意。任何需要几分钟才能理解的单行代码都是维护问题，因此应该重写。（在这种情况下，代码显然是“坏的”！）
我应该如何重写它？我正在考虑使用适当的 XML 解析器来代替这个 hack 工作，但是，如前所述，我的同事（他有更多的经验和资历）告诉我在被证明损坏之前不要修复它（即，需要一个适当的 XML 解析器）。
@gineer：这是一个很难的问题。适当的 XML 解析器可能会为您提供更健壮的解决方案，但如果您保证 XML 的格式一致、格式正确且符合模式，那么临时解析可能就足够了。但即使是在一个意想不到的地方的额外空间也足以摆脱临时解析，并且存在您可能甚至不会考虑的理论变化。
@gineer：经过进一步思考，我想说您应该使用适当的 XML 解析器，除非您可以保证您永远不会得到格式错误或格式不同的 XML。如果这是一项 Web 服务，请不要忘记有人可能会向您发送糟糕/奇怪的 XML，只是为了看看他们是否可以“破坏”您的服务。

【解决方案6】：

嵌套标签。您将从第一个打开标记开始，跳过任何其他存在并在第一个关闭标记而不是匹配的关闭标记处停止。
在打开标记之前的某处有一个关闭标记（您正在从字符串的开头搜索关闭标记，而不是从打开标记的结尾）

【讨论】：