blocks|key|1487498|text|通常，单元测试处理类的公共接口，理论上认为实现是无关紧要的，只要结果从客户的角度来看是正确的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487499|因此，NUnit不提供任何用于测试非公共成员的机制。|1487500|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Generally, unit testing addresses a class's public interface, on the theory that the implementation is immaterial, so long as the results are correct from the client's point of view.

So, NUnit does not provide any mechanism for testing non-public members.

blocks|key|1487534|text|单元测试的主要目标是测试类的公共方法。这些公共方法将使用那些私有方法。单元测试将测试公开可用的行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487535|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The main goal of unit testing is to test the public methods of a class. Those public methods will use those private methods. Unit testing will test the behavior of what is publicly available.

blocks|key|1702648|text|你不需要测试私有函数。有一些方法可以使用反射进入私有方法和属性。但这并不容易，我强烈反对这种做法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1702649|你不应该简单地测试任何非公开的东西。|1702650|如果您有一些内部方法和属性，您应该考虑将其更改为public，或者随应用程序一起提供测试(我并不认为这是一个问题)。|1702651|如果您的客户能够运行一个Test-Suite，并且看到您交付的代码实际上是“工作的”，那么我不认为这是一个问题(只要您不通过此来泄露您的IP+)。我在每个版本中都包含了测试报告和代码覆盖率报告。|1702652|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You don't test private functions.
There are ways to use reflection to get into private methods and properties. But that isn't really easy and I strongly discourage this practice.

You simply shouldn't test anything that's not public.

If you have some internal methods and properties, you should consider either changing that to public, or to ship your tests with the app (something I don't really see as a problem).

If your customer is able to run a Test-Suite and see that the code you delivered is actually "working", I don't see this as a problem (as long as you don't give away your IP through this). Things I include in every release are test-reports and code coverage reports.

blocks|key|1487618|text|编写单元测试的一种常见模式是只测试公共方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487619|如果你发现你有很多私有方法要测试，通常这是你应该重构你的代码的信号。|1487620|在它们当前所在的类上公开这些方法是错误的。这会破坏你想让那个类拥有的契约。|1487621|将它们移到帮助器类并在那里公开它们可能是正确的。此类不能由您的API公开。|1487622|这样测试代码就不会和你的公共代码混在一起了。|1487623|一个类似的问题是测试私有类，即。不能从程序集中导出的类。在这种情况下，您可以使用属性InternalsVisibleTo显式地使您的测试代码程序集成为产品代码程序集的朋友。|1487624|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

A common pattern for writing unit tests is to only test public methods.

If you find that you have many private methods that you want to test, normally this is a sign that you should refactor your code.

It would be wrong to make these methods public on the class where they currently live.
That would break the contract that you want that class to have.

It may be correct to move them to a helper class and make them public there.
This class may not be exposed by your API.

This way test code is never mixed with your public code.

A similar problem is testing private classes ie. classes you do not export from your assembly.
In this case you can explicitly make your test code assembly a friend of the production code assembly using the attribute InternalsVisibleTo.

blocks|key|1702771|text|我会让私有方法包可见。这样一来，您就可以在测试这些方法的同时，使其保持合理的私密性。我不同意有人说公共接口是唯一应该测试的接口。私有方法中经常有真正关键的代码，仅通过外部接口无法正确测试这些代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1702772|因此，这实际上可以归结为您是否更关心正确的代码或信息隐藏。我想说包可见性是一个很好的折衷方法，因为为了访问这些方法，有人必须将他们的类放在你的包中。这真的应该让他们三思而后行，这是否真的是一件明智的事情。|1702773|顺便说一句，我是一个Java爱好者，所以在C#中，包的可见性可能被称为完全不同的东西。可以说，当两个类必须在同一个名称空间中时，才能访问这些方法。|1702774|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I would make the private methods package visible. That way you keep it reasonably private while still being able to test those methods. I don't agree with the people saying that the public interfaces are the only ones that should be tested. There is often really critical code in the private methods that can't be properly tested by only going through the external interfaces.

So it really boils down to if you care more about correct code or information hiding. I'd say package visibility is a good compromise since in order to access those method someone would have to place their class in your package. That should really make them think twice about whether that is a really smart thing to do.

I'm a Java guy btw, so package visiblilty might be called something entirely different in C#. Suffice to say that it's when two classes have to be in the same namespace in order to access those methods.

blocks|key|1487740|text|可以通过将测试程序集声明为正在测试的目标程序集的友元程序集来测试私有方法。有关详细信息，请参阅以下链接：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487741|http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx|offset|length|1487742|这很有用，因为它主要将测试代码从生产代码中分离出来。我自己从来没有使用过这种方法，因为我从来没有发现需要它。我认为您可以使用它来尝试和测试极端测试用例，而您根本无法在测试环境中复制这些用例来查看您的代码如何处理它。|1487743|正如前面所说的，你真的不需要测试私有方法。你比likley更想把代码重构成更小的构建块。当你进行重构时，一个可能会对你有所帮助的技巧是，尝试并思考与你的系统相关的域，并考虑驻留在该域中的“真实”对象。系统中的对象/类应该与真实的对象直接相关，这将允许您隔离对象应该包含的确切行为，并限制对象的职责。这将意味着您正在进行逻辑重构，而不仅仅是为了测试特定的方法；您将能够测试对象的行为。|1487744|如果你仍然觉得有必要进行内部测试，那么你可能还想考虑在测试中使用mocking，因为你很可能只想专注于一段代码。Mocking是将对象依赖项注入其中，但注入的对象不是“真实”或生产对象。它们是具有硬编码行为的虚拟对象，以便更容易地隔离行为错误。Rhino.Mocks是一个流行的免费模拟框架，它本质上会为你编写对象。TypeMock.NET+(一个带有社区版的商业产品)是一个更强大的框架，可以模拟CLR对象。对于模拟SqlConnection/SqlCommand和Datatable类非常有用，例如在测试数据库应用程序时。|1487745|希望这个答案能为您提供更多的信息，让您了解单元测试的一般情况，并帮助您从单元测试中获得更好的结果。|1487746|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1H|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@$D|W|E|X|1|Y]]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|C]]]]

It is possible to test private methods by declaring your test assembly as a friend assembly of the target assembly you are testing. See the link below for details:

<a href="http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx" rel="noreferrer">http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx</a>

This can be useful as it does mostly seperate your test code from your production code. I have never used this method myself as i have never found a need for it. I suppose that you could use it to try and test extreme test cases which you simply can't replicate in your test environment to see how your code handles it. 

As has been said though, you really shouldn't need to test private methods. You more than likley want to refactor your code into smaller building blocks. One tip that might help you when you come to refactor is to try and think about the domain that your system relates to and think about the 'real' objects that inhabit this domain. Your objects/classes in your system should relate directly to a real object which will allow you to isolate the exact behaviour that the object should contain and also limit the objects responsibilities. This will mean that you are refactoring logically rather than just to make it possible to test a particular method; you will be able to test the objects behaviour.

If you still feel the need to test internal then you might also want to consider mocking in your testing as you are likley to want to focus on one piece of code. Mocking is where you inject an objects dependencies into it but the objects injected are not the 'real' or production objects. They are dummy objects with hardcoded behaviour to make it easier to isolate behavioural errors. Rhino.Mocks is a popular free mocking framework which will essentially write the objects for you. TypeMock.NET (a commercial product with a community edition available) is a more powerful framework which can mock CLR objects. Very useful for mocking the SqlConnection/SqlCommand and Datatable classes for instance when testing a database app.

Hopefully this answer will give you a bit more information to inform you about Unit Testing in general and help you get better results from Unit Testing.

blocks|key|1487813|text|如果这不能回答问题，很抱歉，但是使用反射、#if+#endif语句或使私有方法可见等解决方案都不能解决问题。不让私有方法可见可能有几个原因...例如，如果它是生产代码，并且团队正在回溯编写单元测试，该怎么办？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487814|对于我正在处理的项目，似乎只有MSTest+(可悲的是)有一种使用访问器对私有方法进行单元测试的方法。|1487815|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Apologies if this doesn't answer the question but solutions like using reflection, #if #endif statements or making private methods visible does not solve the problem. There can be several reasons for not making private methods visible... what if it's production code and the team is retrospectively writing unit tests for example.

For the project that I am working on only MSTest (sadly) appears to have a way, using accessors, to unit test private methods.

blocks|key|1487872|text|虽然我同意单元测试的重点应该是公共接口，但如果你也测试私有方法，你会对你的代码有一个更细粒度的印象。MS测试框架通过使用PrivateObject和PrivateType实现了这一点，而NUnit则没有。我要做的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487873|private+MethodInfo+GetMethod(string+methodName)
{
++++if+(string.IsNullOrWhiteSpace(methodName))
++++++++Assert.Fail("methodName+cannot+be+null+or+whitespace");

++++var+method+=+this.objectUnderTest.GetType()
++++++++.GetMethod(methodName,+BindingFlags.NonPublic+%7C+BindingFlags.Instance);

++++if+(method+==+null)
++++++++Assert.Fail(string.Format("{0}+method+not+found",+methodName));

++++return+method;
}|code-block|syntax|javascript|1487874|这种方式意味着您不必为了提高可测试性而折衷封装。记住，如果你想测试私有的静态方法，你需要修改你的BindingFlags。上面的例子仅仅是实例方法。|1487875|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

While I agree that the focus of unit testing should be the public interface, you get a far more granular impression of your code if you test private methods as well. The MS testing framework allows for this through the use of PrivateObject and PrivateType, NUnit does not. What I do instead is:

<pre><code>private MethodInfo GetMethod(string methodName)
{
 if (string.IsNullOrWhiteSpace(methodName))
 Assert.Fail("methodName cannot be null or whitespace");

 var method = this.objectUnderTest.GetType()
 .GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);

 if (method == null)
 Assert.Fail(string.Format("{0} method not found", methodName));

 return method;
}
</code></pre>

This way means you don't have to compromise encapsulation in favour of testability. Bear in mind you'll need to modify your BindingFlags if you want to test private static methods. The above example is just for instance methods.

blocks|key|1487930|text|我赞成拥有测试私有方法的能力。当xUnit启动时，它的目的是在编写代码后测试功能。为此，测试接口就足够了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1487931|单元测试已经演变为测试驱动的开发。具有测试所有方法的能力对该应用程序很有用。|1487932|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'm in favor of having the capability to test private methods. When xUnit started it was intended for testing functionality after the code was written. Testing the interface is sufficient for this purpose. 

Unit testing has evolved to test-driven development. Having the capability to test all methods is useful for that application.

blocks|key|1488035|text|这个问题已经很久了，但我想我应该分享我解决这个问题的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1488036|基本上，我在他们正在测试的程序集中的所有单元测试类都在该程序集的“默认”名称空间下的“UnitTest”命名空间中--每个测试文件都包装在一个：|1488037|#if+DEBUG

...test+code...

#endif|code-block|syntax|javascript|1488038|代码块，所有这一切意味着:+a)它没有在发行版中发布；b)我可以使用internal/Friend级别声明，而无需跳跃。|offset|length|style|CODE|1488039|与这个问题更相关的另一件事是partial类的使用，它可以用来创建一个代理来测试私有方法，例如测试返回整数值的私有方法：|1488040|public+partial+class+TheClassBeingTested
{
++++private+int+TheMethodToBeTested()+{+return+-1;+}
}|1488041|在程序集的主类和测试类中：|1488042|#if+DEBUG

using+NUnit.Framework;

public+partial+class+TheClassBeingTested
{
++++internal+int+NUnit_TheMethodToBeTested()
++++{
++++++++return+TheMethodToBeTested();
++++}
}

[TestFixture]
public+class+ClassTests
{
++++[Test]
++++public+void+TestMethod()
++++{
++++++++var+tc+=+new+TheClassBeingTested();
++++++++Assert.That(tc.NUnit_TheMethodToBeTested(),+Is.EqualTo(-1));
++++}
}

#endif|1488043|显然，您需要确保在开发时不使用此方法，尽管如果您这样做了，发布版本很快就会指示对它的无意调用。|1488044|entityMap^0|0|0|0|Y|8|17|6|0|E|7|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|13|8|@$K|14|L|15|M|N]|$K|16|L|17|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@$K|19|L|1A|M|N]]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1B|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1D|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|Z|$]]

This question is in its advanced years, but I thought I'd share my way of doing this.

Basically, I have all my unit test classes in the assembly they're testing in a 'UnitTest' namespace below the 'default' for that assembly - each test file is wrapped in a:

<pre><code>#if DEBUG

...test code...

#endif
</code></pre>

block, and all of that means that a) it's not being distributed in a release and b) I can use <code>internal</code>/<code>Friend</code> level declarations without hoop jumping.

The other thing this offers, more pertinent to this question, is the use of <code>partial</code> classes, which can be used to create a proxy for testing private methods, so for example to test something like a private method which returns an integer value:

<pre><code>public partial class TheClassBeingTested
{
 private int TheMethodToBeTested() { return -1; }
}
</code></pre>

in the main classes of the assembly, and the test class:

<pre><code>#if DEBUG

using NUnit.Framework;

public partial class TheClassBeingTested
{
 internal int NUnit_TheMethodToBeTested()
 {
 return TheMethodToBeTested();
 }
}

[TestFixture]
public class ClassTests
{
 [Test]
 public void TestMethod()
 {
 var tc = new TheClassBeingTested();
 Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
 }
}

#endif
</code></pre>

Obviously, you need to ensure that you don't use this method while developing, though a Release build will soon indicate an inadvertent call to it if you do.

blocks|key|1703191|text|您可以在内部保护您的方法，然后对您的测试命名空间使用assembly:+InternalsVisibleTo("NAMESPACE")。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1703192|因此，不！您不能访问私有方法，但这是一种变通办法。|1703193|entityMap^0|Q|15|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

You can make your methods protected internal, and then using
<code>assembly: InternalsVisibleTo("NAMESPACE")</code>
 to your testing namespace.

Hence, NO! You cannot access private methods, but this is a work-around.

blocks|key|1488128|text|如果您需要访问类的非静态私有方法，可以尝试这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1488129|class+Foo+
{
++++private+int+Sum(int+num1,+int+num2)
++++{
++++++++return+num1+%2B+num2;
++++}
}|code-block|syntax|javascript|1488130|MethodInfo+sumPrivate+=+
++++typeof(Foo).GetMethod("Sum",+BindingFlags.NonPublic+%7C+BindingFlags.Instance);

int+sum+=+(int)sumPrivate.Invoke(new+Foo(),+new+object[]+{+2,+5+});
//+7|1488131|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|D|7|M|8|@]|9|@]|A|$E|F]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

If you need to access a non-static private method of class, could try this:
<pre><code>class Foo 
{
 private int Sum(int num1, int num2)
 {
 return num1 + num2;
 }
}
</code></pre>
<pre><code>MethodInfo sumPrivate = 
 typeof(Foo).GetMethod(&quot;Sum&quot;, BindingFlags.NonPublic | BindingFlags.Instance);

int sum = (int)sumPrivate.Invoke(new Foo(), new object[] { 2, 5 });
// 7
</code></pre>

I am wondering how to use NUnit correctly. First, I created a separate test project that uses my main project as reference. But in that case, I am not able to test private methods. My guess was that I need to include my test code into my main code?! - That doesn't seem to be the correct way to do it. (I dislike the idea of shipping code with tests in it.)

How do you test private methods with NUnit?

How do you test private methods with NUnit?

单元测试

数据库

Java

我想知道如何正确使用NUnit。首先，我创建了一个单独的测试项目，它使用我的主项目作为参考。但在这种情况下，我无法测试私有方法。我的猜测是我需要将我的测试代码包含在我的主代码中？！-这似乎不是正确的方法。(我不喜欢在代码中包含测试的想法。)如何使用NUnit测试私有方法？

问如何使用NUnit测试私有方法？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用NUnit测试私有方法？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用NUnit测试私有方法？
EN