单元测试帮助程序方法？

一种方法是省略测试并将其放在同一包中。然后，测试可以调用内部方法，但其他任何人（= 在包外部）都不能。private

此外，失败的内部方法应该会产生错误消息，从而轻松解决问题。当您将代码投入生产时，您将看到比测试更少的代码，并且您将面临很大的压力来快速解决问题。因此，在这里度过的一分钟将节省一个小时后，你的老板坐在你的脖子上。

这闻起来好像你遇到了错误的问题。你所描述的类似于创建一个子“单元测试”，这让我相信你的单元测试毕竟真的是在测试一个单元。

这并不是对你试图做的事情的批评：从“我们今天所处的位置”到“其他地方明显更好”是一个成功的举动。然而，有人建议你退后一步来评估你所处的位置 - 了解你目前的情况与柏拉图式的理想有何不同，可以帮助展示新的可能性。

这里有很多关于确定帮助程序方法范围的建议。另一种可能性是查看实现，以确定当前实现中是否潜伏着帮助程序类。创建一个新类和一套测试来练习它总是可以接受的。

请注意，此方法使您与重构隔离开来：您可以在不更改测试套件的情况下更改实现（因为即使帮助器对象不再是生产实现的一部分，帮助器对象的单元测试也会继续通过），并且您可以获得实现及其测试的干净打包（用例： 您认为 bozo-sort 是错误的实现，不应再使用。如果 bozo-sort 实现是孤立的，那么只需删除它及其测试即可。但是，当bozo-sort实现的测试与所有其他测试纠缠在一起时，就会涉及更多的思考）。

它还可能有助于查看为什么对代码进行单元测试。如果其中一个原因是“使重构安全”，那么你不想编写将你锁定在实现中的测试。