提取私有方法到另一个类，在该类上进行测试;阅读更多关于SRP原则(单一责任原则)

看起来你需要将私有方法提取到另一个类;在这方面应该是公开的。您应该测试另一个类的公共方法，而不是试图测试私有方法。

我们有以下场景:

Class A
+ outputFile: Stream
- _someLogic(arg1, arg2) 

我们需要测试_someLogic;但A类似乎扮演了过多的角色(违反SRP原则);只需将其重构为两个类

Class A1
    + A1(logicHandler: A2) # take A2 for handle logic
    + outputFile: Stream
Class A2
    + someLogic(arg1, arg2) 

这样就可以在A2上测试一些逻辑;在A1中，只需创建一些伪A2，然后注入到构造函数中，以测试A2被调用到名为someLogic的函数中。

另一个没有提到的选项是创建单元测试类作为您正在测试的对象的子类。NUnit的例子:

[TestFixture]
public class UnitTests : ObjectWithPrivateMethods
{
    [Test]
    public void TestSomeProtectedMethod()
    {
        Assert.IsTrue(this.SomeProtectedMethod() == true, "Failed test, result false");
    }
}

这将允许轻松测试私有和受保护的(但不继承私有)方法，并且允许将所有测试与实际代码分开，这样就不必将测试程序集部署到生产环境中。在许多继承对象中，将私有方法切换为受保护的方法是可以接受的，而且这是一个相当简单的更改。

然而……

虽然这是解决如何测试隐藏方法问题的一种有趣的方法，但我不确定我是否会主张这是在所有情况下解决问题的正确解决方案。在内部测试一个对象似乎有点奇怪，我怀疑在某些情况下，这种方法可能会让您失败。(例如，不可变对象可能会使一些测试非常困难)。

虽然我提到了这种方法，但我认为这更像是一个头脑风暴的建议，而不是一个合理的解决方案。对它持保留态度。

编辑:我发现人们投票否决这个答案真的很滑稽，因为我明确地把它描述为一个坏主意。这是否意味着人们同意我的观点?我很困惑.....

您可以使用嵌套类来测试私有方法。例如(使用NUnit v3):

    
    internal static class A
    {
        // ... other code

        private static Int32 Sum(Int32 a, Int32 b) => a + b;

        [TestFixture]
        private static class UnitTests
        {
            [Test]
            public static void OnePlusTwoEqualsThree()
            {
                Assert.AreEqual(3, Sum(1, 2));
            }
        }
    }

此外，可以使用“部分类”特性将测试相关代码移动到另一个文件中，使用“条件编译”将其排除在发布版本之外，等等。先进的例子:

文件交流

    
    internal static partial class A
    {
        // ... other code

        private static Int32 Sum(Int32 a, Int32 b) => a + b;
    }

文件A.UnitTests.cs

#if UNIT_TESTING
    partial class A
    {
        [TestFixture]
        private static class UnitTests
        {
            [Test]
            public static void OnePlusTwoEqualsThree()
            {
                Assert.AreEqual(3, Sum(1, 2));
            }
        }
    }
#endif

我有另一种适合我的方法。因为我总是在调试模式下运行我的测试，所以我使用#if debug在我的私有方法之前添加public。我的私有方法是这样的

public class Test
{
    #if (DEBUG)
      public
    #endif
    string PrivateMehtod()
    {
      return "PrivateMehtod called";
    }
}

测试私有方法的一种方法是通过反射。这也适用于NUnit和XUnit:

MyObject objUnderTest = new MyObject();
MethodInfo methodInfo = typeof(MyObject).GetMethod("SomePrivateMethod", BindingFlags.NonPublic | BindingFlags.Instance);
object[] parameters = {"parameters here"};
methodInfo.Invoke(objUnderTest, parameters);

这里的另一个想法是将测试扩展到“内部”类/方法，给这种测试更多的白盒意义。您可以在程序集上使用InternalsVisibleTo属性将它们公开给单独的单元测试模块。

结合密封类，你可以达到这样的封装，测试方法只能从单元测试程序集你的方法可见。考虑到密封类中的受保护方法实际上是私有的。

[assembly: InternalsVisibleTo("MyCode.UnitTests")]
namespace MyCode.MyWatch
{
    #pragma warning disable CS0628 //invalid because of InternalsVisibleTo
    public sealed class MyWatch
    {
        Func<DateTime> _getNow = delegate () { return DateTime.Now; };
    

       //construktor for testing purposes where you "can change DateTime.Now"
       internal protected MyWatch(Func<DateTime> getNow)
       {
           _getNow = getNow;
       }

       public MyWatch()
       {            
       }
   }
}

和单元测试:

namespace MyCode.UnitTests
{

[TestMethod]
public void TestminuteChanged()
{
    //watch for traviling in time
    DateTime baseTime = DateTime.Now;
    DateTime nowforTesting = baseTime;
    Func<DateTime> _getNowForTesting = delegate () { return nowforTesting; };

    MyWatch myWatch= new MyWatch(_getNowForTesting );
    nowforTesting = baseTime.AddMinute(1); //skip minute
    //TODO check myWatch
}

[TestMethod]
public void TestStabilityOnFebruary29()
{
    Func<DateTime> _getNowForTesting = delegate () { return new DateTime(2024, 2, 29); };
    MyWatch myWatch= new MyWatch(_getNowForTesting );
    //component does not crash in overlap year
}
}