Joh*_*las 2 refactoring unit-testing design-patterns
我喜欢单元测试,它证明了它在过去一年半的时间里非常值得使用它.但是我总是有一个问题,或者更确切地说是私有方法(和受保护的).
我不想让它们公开或使用属性可见的内部.我想要一个干净清晰的解决方案 - 这是可以测试的,我很自豪能让别人看一看.
我得出的结论是,如果私有方法确实需要独立测试,那么它可能应该被移出到另一个接口并使用关联来向调用方法公开功能.我相信这实际上是Facade模式.
这真的是最好的方法吗?或者更客观地......有没有其他方法我完全被忽视了?
编辑:我们在谈论特定的语言吗?我在C#工作.因为我正在寻找抽象的东西,所以我保留了代码.回到今天,我意识到这可能是愚蠢的,因为语言真的与众不同.
所以一些代码:
public class CopmlexClass
{
public void SomeMethod()
{ }
private void workerMethod()
{ }
}
Run Code Online (Sandbox Code Playgroud)
会被重新考虑进去
public class CopmlexClass
{
public void SomeMethod()
{ }
public IComplexClassWorker Worker { get; set; }
}
public interface IComplexClassWorker
{
void WorkerMethod();
}
Run Code Online (Sandbox Code Playgroud)
事实上,id可能更喜欢使用构造函数注入,甚至不暴露属性
我的问题是:这是最好的方法吗?什么是替代条形反射/内部属性可见?
需要独立测试的私有方法可能是以下结果:
这两种情况通常都是一个明确的调用来提取另一个包含原始类的一些私有方法的类,变成公共的,因此可以直接测试.(有时候具有挑战性的部分是找到逻辑上具有连贯性的功能块,它们本身可以形成有用的类.你可能并不总是得到一个完美的结果 - 在重构中,有时候需要做出妥协,一小步进入一些尚未明确定义的方向.从长远来看,这样的步骤可能会开辟新的可能性,引起对其他类似代码部分的关注,或者新类可能开始从其他地方吸引代码位,最终形成一个连贯的类或者变成一种全新的东西,但比你原先想象的要好.)
通过另一个界面/外观公开私人方法是IMO不会长期解决问题,只会混淆水域.类应该有一个定义良好,完整和最小的接口.以任何方式公开私有方法可能会开辟危害对象内部状态的方法,这是一件坏事.