在单元测试中，setup 方法用于创建测试所需的对象。
在这些设置方法中，我喜欢使用断言：我知道我想在这些对象中看到什么值，并且我喜欢通过断言记录这些知识。
在最近一篇关于单元测试在 stackoverflow 上调用其他单元测试的帖子中，总体感觉似乎是单元测试不应该调用其他测试：这个问题的答案似乎是你应该重构你的设置，以便测试用例不互相依赖。
但是“setup-with-asserts”和调用其他单元测试的单元测试没有太大区别。
因此我的问题是：在设置方法中有断言是一种好习惯吗？
编辑：
答案是：这通常不是一个好习惯。如果设置结果需要测试，建议单独添加一个带有断言的测试方法（答案我勾选了）；要记录意图，请考虑使用 Java 断言。
我没有在设置中使用断言来检查结果，而是使用了一个简单的测试（一种与其他测试方法并列的测试方法，但定位为第一个测试方法）。
我看到了几个优点：
用法和讨论 ：
例如，我将方法命名为 testSetup()。
要使用它，当我在该类中有一些测试错误时，我知道如果 testSetup() 有错误，我不需要为其他错误而烦恼，我需要先修复这个错误。
如果有人对此感到困扰，并希望明确此依赖关系，则可以在 setup() 方法中调用 testSetup()。但我不认为这很重要。我的观点是，在 JUnit 中，您已经可以在其余的测试中拥有类似的东西：
当您读取两者都失败的测试结果时，您已经必须处理不在测试中但在被调用的代码中的这种依赖关系。您必须先修复简单测试，然后重新运行全局测试以查看它是否仍然失败。这就是为什么我不会被我之前解释的隐式依赖所困扰的原因。
Having assertions in the Setup/TearDown methods is not advisable. It makes the test less readable if the user needs to "understand" that some of the test logic is not in the test method. There are times when you do not have a choice but to use the setup/teardown methods for something other than what they where intended for.
There is a bigger issue in this question: a test that calls another test, it is a smell for some problem in your tests. Each test should test a specific aspect of your code and should only have one or two assertions in it, so if your test calls another test you might be testing too many things in that test. For more information read: Unit Testing: One Test, One Assertion - Why It Works
它们是不同的场景；我看不出有什么相似之处。
设置方法应包含（理想情况下）夹具中所有测试通用的代码。因此，如果在测试代码的其余部分执行之前某些事情必须为真，那么在测试设置方法中放置断言本身并没有错。设置是测试的扩展；它是整个测试的一部分。如果断言失败，人们将发现哪个先决条件失败。
另一方面，如果设置足够复杂以至于您觉得需要断言它是正确的，则可能是一个警告信号。此外，如果所有测试都不需要设置的完整输出，则表明该夹具的内聚性较差，应根据场景进行拆分和/或重构。
部分原因是我倾向于远离使用 Setup 方法。在可能的情况下，我使用私有工厂方法或类似方法进行设置。它使测试更具可读性并避免混淆。有时这不切实际（例如，使用紧密耦合的类和/或编写集成测试时），但对于我的大多数测试来说，它可以完成这项工作。
跟随你的心/眨眼的决定。Setup 方法中的断言可以记录意图；提高可读性。所以我个人会支持你。
它与调用其他测试的测试不同——这很糟糕。没有测试隔离。一项测试不应影响另一项测试的结果。
虽然它不是一个频率用例，但我有时会在 Setup 方法中使用 Asserts，这样我就可以知道测试设置是否没有按照我的预期进行；通常当我处理不是我自己编写的组件时。显示“安装失败！”的断言失败 在错误选项卡中 - 快速帮助我专注于设置代码，而不必查看一堆失败的测试。
设置失败通常会导致该夹具中的所有测试失败 - 这是你的鼻子很快就会闻到的气味。'所有测试失败通常意味着安装失败'所以并不总是需要断言。这就是说要务实，看看你的具体情况并“添加口味”。
在需要这样的事情的情况下，我使用 Java 断言，而不是 JUnit 断言。例如，当您使用其他一些实用程序类来设置测试数据时。：
byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;
失败意味着“系统甚至无法尝试运行此测试”。