单元测试辅助方法？

Question

我有以前有大量方法的类,所以我将这个方法的工作细分为'helper'方法.

这些辅助方法被声明private为强制封装 - 但是我想对大型公共方法进行单元测试.对辅助方法进行单元测试也是好的,就好像其中一个方法失败了,调用它的公共方法也会失败,这样我们就可以找出它失败的原因了吗？

另外,为了使用模拟对象测试这些,我需要将其可见性从私有更改为受保护,这是否可取？

Answer 1

这闻起来像你有错误的问题.您所描述的内容类似于创建子单元测试,这让我相信您的单元测试毕竟是在测试一个单元.

这并不是对你要做的事情的批评:从"我们今天所处的位置"到"其他可以改善的地方"是一个成功的举动.然而,建议你退后一步来评估你的位置 - 了解你目前的情况与一些柏拉图式的理想有何不同可以帮助展示新的可能性.

这里有很多关于确定你的助手方法的建议.另一种可能性是检查实现以确定当前实现中是否存在潜伏类.创建一个新的类和一套测试来运用它总是可以接受的.

请注意,这种方法可以使您免于重构:您可以在不更改测试套件的情况下更改实现(因为即使辅助对象不再是生产实现的一部分,辅助对象的单元测试也会继续通过),并且您得到了实现的干净包装及其测试(用例:你认为bozo-sort是错误的实现,不应再使用.如果bozo-sort实现被隔离,那么你只需删除它及其测试.但是当bozo-sort实现的测试与所有其他测试纠缠在一起时,会涉及更多的思考).

它还可以帮助您查看为什么对代码进行单元测试.如果其中一个原因是"使重构安全",那么您不希望编写将您锁定到实现中的测试.

Answer 2

一种方法是省略private并将测试放在同一个包中.然后测试可以调用内部方法,但没有其他人(=在包外).

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

Answer 3

如果你的课真的那么大,那么听起来你应该打破辅助对象,而不仅仅是辅助方法(虽然提取方法通常是一步之遥).完成后,您的旧类变得更简单,更容易测试(可能使用模拟,也许不是),您可以直接在新的支持类上测试方法.

我的偏好是通过对象的公共API进行测试.如果那太难了,那么就暗示该对象应该被打破.

Answer 4

如果您想测试Helper方法，您可以将它们从私有更改，但您可能会考虑这一点。

你不应该对你的实现的私有细节进行单元测试，主要是因为它可能会由于重构和“破坏”你的测试而改变。

Answer 5

我对这里的一些答案感到非常震惊。

本质上，有些人在说“不要测试私有代码，因为这违反了 TDD 范式”

测试该死的代码。做任何你需要做的事情，以确保它完全按照它应该的方式工作。

就个人而言，我会将方法设置为保护或默认，编写测试，运行测试，并在成功后恢复为私有。此时，我将注释掉相关测试，并在其上方留下一个指令块：

/** 对此很抱歉，但我继承了一个烂摊子... * 如果您需要测试这些方法，请在源代码中公开它们并取消注释以下 * 行 */

但是绝对不要让严格遵守开发方法妨碍改进代码。