我在这个答案中看到,对于 Java,您可以在单元测试中将私有方法的可见性设置为“true”以测试该方法。是否有类似的东西可用于 VBA,以便我可以使用 RD-VBA 对私有方法进行单元测试?
如果不是,并且我有一个类可以在三个私有方法中计算出一些逻辑并将其返回给一个返回值,我是否注定只能给出一个输入值并测试返回值,而无法测试三个私有方法在两者之间做举重?
我在这个答案中看到,对于 Java,您可以在单元测试中将私有方法的可见性设置为“true”以测试该方法。是否有类似的东西可用于 VBA,以便我可以使用 RD-VBA 对私有方法进行单元测试?
如果不是,并且我有一个类可以在三个私有方法中计算出一些逻辑并将其返回给一个返回值,我是否注定只能给出一个输入值并测试返回值,而无法测试三个私有方法在两者之间做举重?
无论语言如何,您都不需要为私有方法编写测试。您测试您的公共 API,私有的是不相关的实现细节。
如果它足够相关且重要到可以单独测试,那么您应该将该私有方法提取到另一个类,并将其公开为该类的公共成员。
例如,一旦我有一个表单,并且我想将文本框中的用户输入限制为数字字符,并且由于我在其他地方重用该逻辑而不是将其视为表单的实现细节,我提取了一个AsciiInputValidator
类,它publicIsValidNumericValue
方法可以作为它自己的 SUT 以各种可能的方式进行测试。
不要测试私有方法:公共方法无论如何都会调用它们。
不幸的是,在撰写本文时, Extract Class重构功能尚未实现,因此目前 Rubberduck 无法自动为您执行此操作……但它绝对在范围内,如果您正在阅读本文并且您准备好了一点C# 元编程挑战,去吧,拉请求总是受欢迎的!
您可以添加一个公共包装器,例如
public sub testPrivateSub(param1,param2...)
PrivateSub(param1,param2....)
end sub
private sub PrivateSub(param1,param2....)
....
end sub