条件编译是单元测试的有效模拟/存根策略吗？

发布于 2024-07-05 19:19:09 字数 1268 浏览 7 评论 0原文

在最近关于存根的问题中，许多答案建议使用 C# 接口或委托来实现存根，但是一个答案建议使用条件编译，在生产代码中保留静态绑定。在阅读时，此答案已修改为 -2，因此至少有 2 人确实认为这是一个错误答案。也许滥用 DEBUG 是原因，或者可能使用固定值而不是更广泛的验证。但我不禁想知道：

使用条件编译是否是实现单元测试存根的不合适技术？有时？总是？

谢谢。

编辑-添加：我想添加一个示例作为实验：

class Foo {
    public Foo() { .. }
    private DateTime Now { 
      get {
#if UNITTEST_Foo
        return Stub_DateTime.Now;
#else
        return DateTime.Now;
#endif
      }
    }
    // .. rest of Foo members
}

与 Which 相比

interface IDateTimeStrategy { 
    DateTime Now { get; }
}
class ProductionDateTimeStrategy : IDateTimeStrategy {
  public DateTime Now { get { return DateTime.Now; } }
}
class Foo {
    public Foo() : Foo(new ProductionDateTimeStrategy()) {}
    public Foo(IDateTimeStrategy s) { datetimeStrategy = s; .. }
    private IDateTime_Strategy datetimeStrategy;
    private DateTime Now { get { return datetimeStrategy.Now; } }
}

，允许通过 C# 接口对“DateTime.Now”的传出依赖进行存根。然而，我们现在添加了一个动态调度调用，其中静态就足够了，即使在生产版本中对象也更大，并且我们为 Foo 的构造函数添加了一个新的失败路径（分配可能会失败）。

我在这里什么都不用担心吗？感谢迄今为止的反馈！

原文

In a recent question on stubbing, many answers suggested C# interfaces or delegates for implementing stubs, but one answer suggested using conditional compilation, retaining static binding in the production code. This answer was modded -2 at the time of reading, so at least 2 people really thought this was a wrong answer. Perhaps misuse of DEBUG was the reason, or perhaps use of fixed value instead of more extensive validation. But I can't help wondering:

Is the use of conditional compilation an inappropriate technique for implementing unit test stubs? Sometimes? Always?

Thanks.

Edit-add: I'd like to add an example as a though experiment:

class Foo {
    public Foo() { .. }
    private DateTime Now { 
      get {
#if UNITTEST_Foo
        return Stub_DateTime.Now;
#else
        return DateTime.Now;
#endif
      }
    }
    // .. rest of Foo members
}

comparing to

interface IDateTimeStrategy { 
    DateTime Now { get; }
}
class ProductionDateTimeStrategy : IDateTimeStrategy {
  public DateTime Now { get { return DateTime.Now; } }
}
class Foo {
    public Foo() : Foo(new ProductionDateTimeStrategy()) {}
    public Foo(IDateTimeStrategy s) { datetimeStrategy = s; .. }
    private IDateTime_Strategy datetimeStrategy;
    private DateTime Now { get { return datetimeStrategy.Now; } }
}

Which allows the outgoing dependency on "DateTime.Now" to be stubbed through a C# interface. However, we've now added a dynamic dispatch call where static would suffice, the object is larger even in the production version, and we've added a new failure path for Foo's constructor (allocation can fail).

Am I worrying about nothing here? Thanks for the feedback so far!

分享到QQ

分享到微博