使用中介者模式进行单元测试 - 全部私有到公共
我正在使用中介模式来促进 GUI 对象的单元测试。
伪代码示例:
Class MyGuiClass
{
//... Declare and initialize mediator to be a MyMediator
private void On_SomeButtonPressed()
{
mediator.SomeButtonWasPressed();
}
}
Class MyMeditator
{
public void On_SomeButtonPressed()
{
//.. Do something now that the button was pressed
}
}
这很好,因为我现在可以对按下 SomeButton 时发生的情况进行单元测试,而无需创建窗口。
我担心的是,我采用了一种私有方法,并将其公开给任何调用 Mediator 的人。过去我曾这样做过,但这并没有困扰我,因为我没有太多必须公开的方法。
我目前正在重构一个非常大的类来使用这种模式,我想知道是否有某种方法可以控制谁可以创建 MyMediator 或某些方法对哪些类是公开的可见性。 (这可能不可能,甚至不需要,但我想我会问。)
(我正在使用 C# 3.0 和 .NET 3.5 SP1)
I am using the mediator pattern to facilitate unit testing of GUI objects.
psudo code Example:
Class MyGuiClass
{
//... Declare and initialize mediator to be a MyMediator
private void On_SomeButtonPressed()
{
mediator.SomeButtonWasPressed();
}
}
Class MyMeditator
{
public void On_SomeButtonPressed()
{
//.. Do something now that the button was pressed
}
}
This is nice because I can now unit test what happens when SomeButton is pressed without having to create a Window.
My concern is that I have taken a method that was private and made it public for any one who makes a Mediator to call. Past times I have done this it did not bother me because I did not have many methods that I had to make public.
I am currently refactoring a very large class to use this pattern and I am wondering if there is someway I can control the visibility of who can make a MyMediator or which classes some of the methods are public for. (This may not be possible or even needed, but I thought I would ask.)
(I am using C# 3.0 with .NET 3.5 SP1)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为这并不重要.. 除了 gui 之外,谁有调解器的实例?如果有人这样做,它会调用该方法吗?如果是的话,有什么关系吗?是否很难发现、诊断和修复错误?
我认为你可以通过事件实现你正在寻找的东西:
例如
I think it doesn't matter.. Who has an instance of the mediator, other than the gui? If someone does, is it going to call the method? If it does, does it matter? Will it be hard to notice, diagnose and fix the bug?
I think you can achieve what you are looking for with events though:
e.g.
不确定 c#,但在 java 中,您可以将某些内容声明为包级访问(在 java 中,通过省略访问说明符)。我所做的是创建一个与我的包结构并行的单独的测试层次结构,因此为了测试类 com.abcMyClass,我将有一个测试类 com.abcMyClassTest,然后它可以合法地访问 MyClass 中的包访问方法。
我不太喜欢将所有内容公开的想法,不仅因为访问问题,而且因为它使界面变得混乱 - 我宁愿类的公共接口表达它的作用,不是如何它是如何做到的,如果我公开我希望私有的方法,这通常是我最终的结果。
Not sure about c#, but in java you can declare something as package-level access (in java by omitting the access specifier). What I do is create a separate test hierarchy that parallels my package structure, so to test class com.a.b.c.MyClass, I'll have a test class com.a.b.c.MyClassTest, which can then legally access the package-access methods in MyClass.
I don't so much like the idea of making everything public not only because of access issues, but because it clutters up the interface - I'd rather the public interface of the class express what it does, not how it does it, which is often where I end up if I expose methods I'd prefer to be private.
关键是,您希望类的公共接口显示该类的公共“API”,因此在将私有方法设为公共时,您是否会使该类变得更加混乱且不那么“干净”?
您可以做一些事情:
1)思考一下你的中介者(或卑微的对象)类的“公共面孔”实际上是什么,并愉快地将这些方法公开。即使它们仅在程序集中使用 - 不是程序集公共面孔的一部分 - 也没关系,因为请注意,您的中介类本身并未声明为公共。因此,即使它的公共方法仍然是程序集内部的。
2)您可以通过使用内部为私有来伪造私有(如果您的测试类位于单独的程序集中,然后设置程序集的InternalsVisibleTo属性)。
3)采用“黑盒”方法进行单元测试,原则上您永远不需要测试私有方法,因为它们在从公共方法调用时通过使用进行测试。
The point is that you'd like the public interface of a class to show that class's public 'API', so in making private methods public you are making the class more confusing and less 'clean'?
A few things you can do:
1) think through what actually is the 'public face' of your mediator (or humble object) class and happily make those methods public. Even if they are only used within the assembly - not part of the assembly's public face - that's okay because notice that your mediator class itself is not declared public. So even its public methods are still internal to the assembly.
2) You can fudge the privates by using internal for private (and then set the assembly's InternalsVisibleTo attribute if your test classes are in a separate assembly).
3) Take the 'black box' approach to unit testing whereby in principle you never need to test the privates because they get tested via their use when called from the public methods.