单元测试:在设置方法中使用断言是一个好的实践吗?

而不是设置中用于检查结果的断言, 我用了一个简单的测试 (与其他测试方法一起使用,但作为第一种测试方法)。

我看到了几个优势:

• 这个 设置保持简短和集中 ,用于可读性。
• 断言只运行一次,即 有效率的 .

使用和讨论 :

例如,我将方法命名为testsetup()。

要使用它,当我在那个类中有一些测试错误时,我知道如果testsetup()有一个错误,我不需要为其他错误操心,我需要首先修复这个错误。

如果有人对此感到困扰,并希望将此依赖关系显式化,则可以在setup()方法中调用testsetup()。但我认为这不重要。我的观点是,在JUnit中,您的其余测试中可能已经有类似的内容:

1. 一些测试测试本地代码,
2. 还有一些测试调用了更多的全局代码,这些代码间接调用了与前一个测试相同的代码。

当你读到两个都不合格的测试结果时, 您必须处理这个依赖项,它不在测试中,而是在被调用的代码中。 . 您必须首先修复简单测试,然后重新运行全局测试,以查看它是否仍然失败。 这就是为什么我不为我之前解释过的隐性依赖所困扰的原因。

它们是不同的场景;我看不到相似性。

安装方法应该包含常见的代码(理想情况下) 全部的 在夹具中测试。因此,如果在测试代码的其余部分执行之前某些事情必须是真的,那么在测试设置方法中放置断言并没有本质上的错误。设置是测试的扩展;它是整个测试的一部分。如果断言跳闸,人们会发现哪个先决条件失败了。

另一方面,如果设置足够复杂,您认为需要断言它是正确的,那么它可能是一个警告标志。此外,如果所有测试都不需要安装程序的完整输出,那么这就表明该设备的内聚性较差,应该根据场景和/或重构进行拆分。

部分原因是我倾向于远离使用设置方法。在可能的情况下,我使用私人工厂方法或类似方法来设置。它使测试更具可读性并避免混淆。有时这是不实际的(例如,使用紧密耦合的类和/或编写集成测试时),但对于我的大多数测试来说,它都能完成工作。

不建议在设置/拆卸方法中使用断言。如果用户需要“理解”某些测试逻辑不在测试方法中,它会降低测试的可读性。 有时,您没有选择,只能将设置/拆卸方法用于其他用途。

这个问题有一个更大的问题:一个调用另一个测试的测试,它是测试中某个问题的味道。 每个测试都应该测试代码的一个特定方面,并且应该只有一个或两个断言,所以如果测试调用另一个测试,那么在该测试中测试的东西可能太多了。 有关详细信息,请阅读: Unit Testing: One Test, One Assertion - Why It Works

听从你的决定。设置方法中的断言可以记录意图;提高可读性。所以我个人会支持你。
它不同于调用其他测试的测试-这很糟糕。无测试隔离。一项测试不应影响另一项测试的结果。

虽然它不是一个频率用例,但我有时会在设置方法中使用断言,这样我就可以知道测试设置是否没有按照我的预期进行;通常是在我处理自己没有编写的组件时。一个断言失败,它读取“安装失败!”在“错误”选项卡中-快速帮助我了解设置代码,而不必查看一堆失败的测试。

设置失败通常会导致该夹具中的所有测试失败,这是一种您的鼻子很快就会闻到的气味。所有测试失败通常意味着设置中断,因此并不总是需要断言。那就是说要务实,看你的具体情况,并“增加品味”。

在这种情况下,我需要使用Java断言,而不是JUnit。例如,当使用其他实用程序类设置测试数据时:

byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;

失败意味着“系统不处于甚至 尝试 运行此测试。