有时候我想在方法中测试一个中间值。但该方法无法拆分。所以我想知道JUnit是否只能将方法作为一个单元进行测试。如果我可以在方法中放入类似断点的东西，并获取本地值并断言它，那就更好了。如果不可能，你如何解决这类问题。
答案 0 :(得分：6)
添加断点并不是单元测试，实际上根本没有测试。您可以将其称为检查，但不存在Check Driven Development。
无论如何，对单元测试不熟悉的人经常发现他们想要测试私有或本地值的这个问题，让它成为一个变量或方法。当我开始使用TDD时，事实上我自己已经完全分阶段了。但问题是，在单元测试中，目的是对特定功能进行黑盒测试，并从中进行所有可能的结果。黑盒子里面发生的事情不是你的问题，也不需要进行单元测试。
如果你想测试一个中间值，那么你的方法可能太长了，应该分成两个或多个可测试的小方法。如果无法完成，那么你不应该担心测试它们。
如果该中间值从另一个公共方法获取其值，则 方法要在单独的单元测试中测试，而不是您当前正在测试的方法中的值。
答案 1 :(得分：2)
你的问题导致对TDD中D的解释。特别是当您使用TDD来表示“测试驱动设计”时（尽管有些人更喜欢“测试驱动开发”这一短语）。
正如@Shahzeb指出的那样，也许你的方法太长了，应该分成两个方法，其中一个产生中间值，另一个产生输入。我们倾向于以这种方式思考代码，这些测试确实是驱动。我们的代码的设计更好，因为我们将关注点分开，以便能够开始测试它们。所以你提出了一个很好的问题（其简短的答案是“不”），这些是允许TDD改进我们设计的问题。
答案 2 :(得分：1)
这个想法是你根本不测试私有（中间）值，因为它不是外部重要的（这就是为什么你明智地将它保密。）私有值表示您现在设置的对象中的某个状态意图是它将影响将来对您的公共接口的调用，对吧？因此，更改您的一个测试以进行两次调用。让第一个调用按照您认为应该的方式执行所需的任何操作，然后进行第二次调用，并在设置该变量时看到它产生您期望的方式。如果它是真正私密的，那么它对单元测试的价值并不重要 - 只要它能在正确的时间正确地产生所需的结果。但是这个建议伴随着一个警告：它正在进入那个地盘，你可能要求单元测试做的不仅仅是一个单位的测试。
另一个观察结果：你说你的方法＆＃34;不能分开＆＃34;但是没有提供解释原因。如果您无法改变设计，那么听起来更像是您可能尝试将单元测试融入遗留代码，而不是执行测试驱动开发。这完全没问题，你不必在这里放弃TDD，但也许还有其他方法需要考虑。一旦你通过了测试，在TDD中你可以稍微重构一下这个方法。您谈论中间价值这一事实表明您的方法有太多责任。考虑使用extract方法将更简洁的功能部分封装到更小的可测试服务方法中。
如果这不是你想要完成的事情，那么你尝试执行的测试可能是在考虑太大了＃34;也许您尝试做的测试更多的是验收测试。同样，那很好，验收测试也非常重要，但它不再是一个单元测试。