1

首先，我想承认我理解这些是具有各自目的领域的独立概念。

话虽如此，我偶尔会发现自己想知道处理某事的最佳方式是使用合同、良好的测试还是使用不当时的异常。

举个例子，对输入的非平凡要求，如健全性检查和验证，这些是合同的领域还是由异常更好地处理？如果它们不是例外而只是违反设计怎么办？如果它们不会导致不可预测的行为，而只会导致潜在的不良或“惊人”行为怎么办？您可能会争辩说，这种设计歧义是一种代码味道，但有时至少在实用主义允许的范围内是不可避免的。

我想知道是否有人愿意提供有关此主题的指南？

4

2 回答 2

2

合约不应该成为最终用户控制的代码输入导致的不正确输入的失败模式。只有在开发过程中才能接受合同失败。在生产过程中，可以记录合同失败以供开发人员将来检查。因此，如果您的输入需要验证，请验证它，不要让合同失败。

也就是说，如果您构建了一个库，并且您的输入来自其他开发人员编写的代码，那么合约是告诉其他开发人员输入不可接受的好方法。

于 2013-06-06T22:28:42.267 回答
1

我认为这完全取决于您要通过测试完成什么。实际上，我使用合同和断言比其他任何东西都多。作为一般规则，测试不应该try/catch通过块抛出异常。相反，您应该更谨慎地处理异常，例如，将其包装，然后在独立于您的测试类的另一个类中处理它。

使用契约是为您的测试设置前置条件以使其更加专注的好方法。正如我已经提到的，我使用这些并断言比什么都重要。使用我们的框架（Selenium WebDriver），我们使用'@Test'来标记这是一个测试，然后通过调用它适合的'bucket'来赞美它，如@Category(SomeTestClass.class).

使用断言时，请务必记住您使用的是哪种类型。有些停止代码执行，而另一些则允许“失败”（很像在switch/case语句中）。此外，在使用它们时，我们会尝试设置断言，以便您以一个True条件结束，而不是一个错误的条件。很像这样：

assertTrue("Product breadcrumbs not showing", productCQPage.areBreadCrumbsShowing());

在上面的示例中，我使用布尔值来验证是否显示面包屑，在这种情况下，只有当该布尔值返回 false 时才会触发断言。再说一次，我是带着否定的态度进入的，但肯定是肯定的。令人困惑，对吧？:)

我希望这在某种程度上对你有帮助！

于 2013-06-05T16:56:52.273 回答