c# - 保持源代码关闭，单元测试更接近

Question

当我第一次开始使用单元测试时，我遇到了两个问题。首先是能够测试私有(private)方法和字段，其次是在快速开发发生时无法及时更新单元测试。因此，我采用了以下方法进行单元测试。

#if UNITTEST
using NUnit.Framework;
#endif

public class MyBlackMagic
{
   private int DoMagic()
   {
      return 1;
   }

   #if UNITTEST

   [TestFixture]
   public class MyBlackMagicUnitTest
   {
        [TestFixtureSetUp]
        public void Init()
        {
             log4net.Config.BasicConfigurator.Configure();
        }

        [Test]
        public void DoMagicTest()
        {
             Console.WriteLine(System.Reflection.MethodBase.GetCurrentMethod().Name);
             Assert.IsTrue(DoMagic() == 1, "You are not a real magician!");
         }
     }

     #endif
 }

我发现这种方法解决了我的两个问题，只需轻轻一按预编译器开关即可确保所有单元测试都能编译。

我现在的问题是我要转到一个新项目，该项目讨论使用单独的程序集来进行单元测试。在我深入并开始阐述如上所示的内部类方法的优点之前，我想知道是否有人认为它有任何缺点？

编辑:

只是针对提到的一些弱点补充几点:

• 单元测试代码永远不会影响生产代码，因为 UNITTEST 预编译器标志已关闭，
• 单元测试代码不会降低主要代码的可读性，因为它位于每个类的底部并包含在 Visual Studio 区域指令中，
• 我发现内部单元测试类意味着主类实际上更简单，因为没有为了测试而必须公开的额外方法或属性。总会有这样的情况，您迟早要测试类的某些内部状态作为单元测试的一部分...

Answer 1

我发现这种方法非常丑陋，因为它用测试方法混淆了您的真实逻辑，使您的源代码更难阅读。

除此之外，您还具有对项目本身中的 NUnit 程序集的依赖性(引用)。虽然在没有 unit_test 条件定义的情况下编译时不需要依赖关系，但这很丑陋且不必要。

如果你想跟上你的单元测试，我建议你先写测试，然后再实现真正的代码。

编写单元测试不仅仅是测试；它还与设计代码有关。

通过先编写测试，您将开始考虑类的 API/接口(interface)，或者您希望如何使用这些类。