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

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

#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区域指令中,

我发现内部单元测试类意味着主类实际上更简单,因为没有额外的方法或属性只是为了测试而暴露.总会有一些情况,你想早晚测试一个类的内部状态作为单元测试的一部分......

Frederik Ghe.. 12

我发现这种方法非常难看,因为它会使用测试方法混淆你的真实逻辑,使你的源更难阅读.

除此之外,您还对项目本身的NUnit程序集具有依赖项(引用).虽然在没有unit_test条件定义的情况下编译时不需要依赖,但这很简单且不必要.

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

编写单元测试更多的是测试; 它也是关于设计代码.

通过先编写测试,您将会想到您的类的API /接口,或者您希望如何使用这些类.

1> Frederik Ghe..：

---

我发现这种方法非常难看,因为它会使用测试方法混淆你的真实逻辑,使你的源更难阅读.

除此之外,您还对项目本身的NUnit程序集具有依赖项(引用).虽然在没有unit_test条件定义的情况下编译时不需要依赖,但这很简单且不必要.

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

编写单元测试更多的是测试; 它也是关于设计代码.

通过先编写测试,您将会想到您的类的API /接口,或者您希望如何使用这些类.

---

首先编写测试不是关于具有易于测试的设计; 这是关于拥有良好的整体/可用课程设计.结果你得到的测试是额外的奖励.无论如何,你编写的软件毕竟需要进行测试,所以为什么不多花一些时间来编写一个测试..

2> Björn..：

---

您不应该单独测试私有方法,因为它们(应该是!)从公共方法或可能的构造函数中使用 - 因此公共方法依赖于私有方法来成功完成其分配.

如果私有方法不起作用,这些公共方法/构造函数将(应该!)失败.所以你的方法实际上是编写单元测试的坏方法.

并迭代以前的答案 - 在编写方法之前编写单元测试.

3> Gerrie Schen..：

---

如果您无法在所有时间内保持所有测试成功(因为开发截止日期),那么我认为您的单元测试非常严重,并且在进行估算时应考虑维护测试.