单元测试专用代码 [英] Unit testing private code

问题描述

我目前参与用C＃开发 - 这里是一些背景：
我们与客户端应用程序实现MVP和我们有规定，任何方法应该有一个圈复杂度大于5 $ B一个圈规则$ b这导致了很多小私有方法这是通常负责一件事

I am currently involved in developing with C# - Here is some background: We implement MVP with our client application and we have a cyclomatic rule which states that no method should have a cyclomatic complexity greater than 5. This leads to a lot of small private methods which are generally responsible for one thing.

我的问题是关于单元测试类：

My question is about unit testing a class:

通过测试的公共方法私有实现是所有罚款...我没有实施这是一个问题。

Testing the private implementation through the public methods is all fine... I don't have a problem implementing this.

但是......怎么样了以下情况：

But... what about the following cases:

例1。处理异步数据retrival请求的结果（回调方法不应该是纯粹为了测试公众）

Example 1. Handle the result of an async data retrival request (The callback method shouldn't be public purely for testing)

示例2。 事件处理这确实的操作（如更新查看标签的文本 - 例如傻，我知道...）

Example 2. An event handler which does an operation (such as update a View label's text - silly example I know...)

示例3 您正在使用第三方的框架，允许您通过重写受保护的虚拟方法（从公共的方法对这些虚方法的路径一般被视为黑箱编程扩展，将有该框架提供了各种依赖关系的你不想知道）

Example 3. You are using a third party framework which allows you to extend by overriding protected virtual methods (the path from the public methods to these virtual methods are generally treated as black box programming and will have all sorts of dependancies that the framework provides that you don't want to know about)

上面的例子并不在我看来是设计不良的结果。
他们也不会出现被成为候选人转移到一个单独的类测试隔离因为这些方法将失去他们的背景。

The examples above don't appear to me to be the result of poor design. They also do not appear be be candidates for moving to a seperate class for testing in isolation as such methods will lose their context.

没有按任何人有任何想法这个

Doesn anyone have any thoughts about this?

干杯，
杰森

编辑：
口不认为我是在我原来的问题很清楚 - 我可以测试使用访问私有方法和使用TypeMock模拟出的呼叫/方法。这是没有问题的。问题是测试事情不需要是公共的，或者可以不公开。

I don't think I was clear enough in my original question - I can test private methods using accessors and mock out calls/ methods using TypeMock. That isn't the problem. The problem is testing things which don't need to be public, or can't be public.

我不想让代码公开测试的缘故，因为它会带来安全漏洞（只发布到隐藏这个接口是不是一种选择，因为任何人都可以只投​​对象回原来的类型和获取的东西，我不希望出现这种被重构到另一个类测试他们）

I don't want to make code public for the sake of testing as it can introduce security loopholes (only publishing an interface to hide this is not an option because anyone can just cast the object back to its original type and get access to stuff I wouldn't want them to)

代码是好的 - 但可能会失去环境。我一直认为这是不好的做法有它可以包含代码锅没有具体的语境'助手'类 - （这里想SRP）。我真的不认为这无论是对工作的事件处理程序

Code that gets refactored out to another class for testing is fine - but can lose context. I've always thought it bad practice to have 'helper' classes which can contain a pot of code with no specific context - (thinking SRP here). I really don't think this works for event handlers either.

我很高兴被证明是错误的 - 我只是不能确定如何测试这个功能！我一直头脑的，如果它能够打破或改变 - 测试

I am happy to be proven wrong - I just am unsure how to test this functionality! I have always been of the mind that if it can break or be changed - test it.

干杯，杰森

推荐答案

由于克里斯曾表示，它是标准的做法是只单元测试公共方法。这是因为，作为对象的消费者，你只关心的是公开提供给您。而且，从理论上讲，与边缘的情况下适当的单元测试将充分发挥他们所有的私有方法的依赖关系。

As Chris has stated, it is standard practice to only unit test public methods. This is because, as a consumer of that object, you are only concerned about what is publically available to you. And, in theory, proper unit tests with edge cases will fully exercise all private method dependencies they have.

话虽这么说，我发现有几次在这里写单元测试直接针对私有方法可以是非常有用的，在解释最简洁，通过你的单元测试，一些比较复杂的方案或可能遇到的边缘情况。

That being said, I find there are a few times where writing unit tests directly against private methods can be extremely useful, and most succinct in explaining, through your unit tests, some of the more complex scenarios or edge cases that might be encountered.

如果是这样的话，你可以使用反射调用还是私有方法。

If that is the case, you can still invoke private methods using reflection.

MyClass obj = new MyClass();
MethodInfo methodInfo = obj.GetType().GetMethod("MethodName", BindingFlags.Instance | BindingFlags.NonPublic);
object result = methodInfo.Invoke(obj, new object[] { "asdf", 1, 2 });
// assert your expected result against the one above

这篇关于单元测试专用代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！