相关疑难解决方法(0)

保持您的源关闭和您的单元测试更紧密

当我第一次开始使用单元测试时遇到了两个问题.首先是能够测试私人方法和领域,然后在快速开发发生时保持单元测试的最新状态.因此,我采用了以下方法进行单元测试.

#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
 }
Run Code Online (Sandbox Code Playgroud)

我发现这种方法克服了我的两个问题,它是一个预编译器开关的轻弹,以确保所有单元测试编译.

我现在的问题是,我正在转向一个新的项目,其中的谈话是使用单独的程序集来进行单元测试.在我深入研究并开始阐述内部类方法的优点之前,如上所示,我想知道是否有人认为它有任何缺点?

编辑:

只是为了解一些提到的弱点:

  • 由于UNITTEST预编译器标志被关闭,单元测试代码永远不会影响生产代码,
  • 单元测试代码不会使主代码的可读性降低,因为它放在每个类的底部并包装在Visual Studio区域指令中,
  • 我发现内部单元测试类意味着主类实际上更简单,因为没有额外的方法或属性只是为了测试而暴露.总会有一些情况,你想早晚测试一个类的内部状态作为单元测试的一部分......

c# nunit unit-testing

4
推荐指数
3
解决办法
815
查看次数

标签 统计

c# ×1

nunit ×1

unit-testing ×1