Question

我喜欢单元测试，它证明了它在过去一年半的时间里非常值得使用它。但是我总是有一个问题，或者更确切地说是私有方法（并且受保护）。

我不想公开它们或使用属性可见的内部。我想要一个干净清晰的解决方案 - 这是可以测试的，我很自豪能让别人看看。

我得出的结论是，如果私有方法真的需要独立测试，那么它可能应该被移出到另一个接口并使用关联来向调用方法公开这些功能。我相信这实际上是Facade模式。

这真的是最好的方法吗？或者更客观地......是否有其他方法我完全忽略了？

编辑：我们在谈论特定的语言吗？我在C＃工作。因为我正在寻找一些抽象的东西，所以我保留了代码。回到今天，我意识到这可能是愚蠢的，因为语言真的与众不同。

所以有些代码：

public class CopmlexClass
{
    public void SomeMethod()
    { }

    private void workerMethod()
    { }
}

将被重新考虑到

public class CopmlexClass
{
    public void SomeMethod()
    { }

    public IComplexClassWorker Worker { get; set; }

}

public interface IComplexClassWorker
{
    void WorkerMethod();        
}

事实上，id可能更喜欢使用构造函数注入，甚至不公开属性

我的问题是：这是最好的方法吗？什么是替代条形反射/内部可见属性？

Answer 1

需要独立测试的私有方法可能是以下结果：

你的课程做得太多了 - 它的公共方法实现的功能太复杂了，无法作为一个整体进行单元测试，和/或
无法从课外直接感知调用特定私有方法的效果。

这两种情况通常都是一个明确的调用来提取另一个包含原始类的一些私有方法的类，变成公共的，因此可以直接测试。（有时候具有挑战性的部分是找到逻辑上具有连贯性的功能块，它们本身可以形成有用的类。你可能并不总是得到一个完美的结果 - 在重构中，有时候需要做出妥协，一小步进入一些尚未明确定义的方向。从长远来看，这样的步骤可能会开辟新的可能性，引起对其他类似代码部分的关注，或者新类可能开始从其他地方吸引代码位，最终形成一个连贯的类或者变成一种全新的东西，但比你原先想象的要好。）

通过另一个界面/外观暴露私人方法是IMO不会长期解决问题，只会混淆水域。类应该有一个定义良好，完整和最小的接口。以任何方式公开私有方法可能会开辟危害对象内部状态的方法，这是一件坏事。

Answer 2

几年前，当我们开始在我们的团队中编写单元测试时，我们开始使用您在上面列出的规则 - 即我们测试程序集的公共接口。

我们期望检测无法访问的代码有一个好处。如果代码覆盖率工具检测到未测试的代码块，则缺少测试或代码无法访问，应删除。

但在实践中我们并没有坚持下去。我们有一个非常模块化的设计 - 在我们的主要解决方案中有超过30个项目（大多数都有匹配的单元测试项目）。我们现在通常会让测试项目访问被测项目的内部。

我认为一个问题是我们不会自动使用代码覆盖来检测丢失的测试或无法访问的代码。因为这是一个手动过程，所以无法完成。

单元测试：私有方法以及如何重构

2 个答案: