Question

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

#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 /接口，或者您希望如何使用这些类。

Answer 2

你不应该单独测试私有方法，因为它们（应该是！）来自公共方法或可能的构造函数 - 因此公共方法依赖于私有方法来成功完成它们的分配。

如果私有方法不起作用，这些公共方法/构造函数将（应该！）失败。所以你的方法实际上是编写单元测试的坏方法。

要迭代之前的答案 - 在编写方法之前编写单元测试。

Answer 3

如果您不能一直保持所有测试成功（因为开发截止日期），那么我认为您的单元测试非常严重，并且在进行估算时应考虑维护测试。

Answer 4

我发现将我的单元测试保存在他们自己的程序集中非常有效，并且在使用它时没有遇到任何问题。

但是，如果你发现自己需要测试某些类的私人成员，那可能意味着你的班级正在做很多事情。您可能最好将这些私有成员提取到一个新类中。然后，您可以通过其公共方法直接测试该新类。

Answer 5

我认为这不是单元测试的设计目标。如果您已快速开发代码并且单元测试落后，那么它们当然会失败，但这不应该导致您使用黑魔法，而是编写单元测试。如果您不喜欢这种方式，那么您根本不应该使用单元测试。

Answer 6

将测试代码保存在自己的单独程序集中的基本原理是因为测试代码不应被用户“使用”。单元测试仅用于验证代码是否执行了指定的操作。通常的做法是将测试代码放在它自己的程序集中，这样生产代码就不依赖于测试代码和单元测试框架。

从这个代码示例中，我不清楚你要测试的是什么。看起来你正试图测试一些与环境完全隔离的东西。当xUnit测试运行器可以为您记录测试结果时，为什么还需要记录器？

内部类很难测试，因为你需要一个内部类正在实现的公共接口（或抽象类），你需要与创建它的类一起测试它。更明确的单元测试应检查一个特定类的行为，如果以某种方式返回内部类，则需要检查它是否以正确的方式返回。

Answer 7

请问，您是如何对任何已将UNITTEST设置为false的构建进行单元测试的？

我是一个蹩脚，懒惰的TDD实施者。我没有在足够的测试附近写任何东西，而且我也不经常运行它们。但即使我测试我的发布版本。

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

7 个答案: