我应该使用回调还是引入公共字段来帮助进行单元测试？

Question

我见过在单元测试艺术中添加公共属性(由Roy倡导)，以帮助获取和设置SUT使用的尴尬(或内部)协作者/协作，并且自己使用了这种技术取得了很好的效果。(我还看到了一种类似的使用附加构造函数的方法)

类似地，测试隔离框架(如莫克)可以提供替代方案，并且可以使用Moq回调来帮助设置尴尬的协作者/协作。

我在这里经历过的是：

使用公共字段在SUT中引入附加项，使用稍微干净的测试代码。

对比

一个由额外项目组成的集合，使它具有可测试性，并且测试代码稍显笨重(回调代码并不是最漂亮的)。

在我的情况下，并且由于对什么是命令的限制，并且应该是一个查询--一个可以返回存根数据的查询，在SUT中管理协作是不容易的(没有，，前面提到的机制)。

SUT中的协作者更新命令中引用传递的对象，这看起来是lik：(稍后在代码示例中重复)

  var warehouse = new Warehouse(); // internal to Order
  _repo.Load(warehouse); // Warehouse is filled by reference

编辑:我设计了一个存在设计问题的例子--仓库和订单过于亲密，应用程序服务可以用来调度交互等等。问题的核心是，我对仓库的填充方式几乎没有控制。我正在使用一个框架，它使用一个命令来引用一个对象的水合物。这是问题所在，我知道，但不幸的是，我受到它的限制。因此，这个问题的真正焦点不是重新设计，而是纯粹的哪种方法，回调或公共领域将是更好的，如果这是我们必须处理的全部。

下面的代码示例都是使用Moq和NUnit的工作示例。出于时间的考虑，我省略了添加应用程序服务来编排示例用例(这基本上是根据福勒的模拟不是Stubs示例从一个兼容的仓库中填充订单)。另外，这两种方法都采用经典的单元测试方法，断言状态而不是验证行为，这不是我想要关注的问题。

在继续之前，我确实有一个偏好，但我会有兴趣看看其他人建议或喜欢什么。

因此，首先是公共属性方法、代码和测试：(在使用Func<>方面很聪明)

public class Order
{
    private readonly IWarehouseRepo _repo;
    public int Items { get; private set; }

    public Func<Warehouse> WarehouseBuilder { get; set; }

    public Order(IWarehouseRepo repo)
    {
        _repo = repo;
    }

    public void AddOrderItems(int numberOfItems)
    {
        var warehouse = WarehouseBuilder();
        _repo.Load(warehouse);
        warehouse.RemoveStock(numberOfItems);
        Items += numberOfItems;
    }
}

public class Warehouse
{
    public int Items { get; set; }

    public void RemoveStock(int numberOfItems)
    {
        Items -= numberOfItems;
    }
}

[TestFixture]
public class Given_A_Warehouse_With_20_Items
{
    private Order _order;
    private Mock<IWarehouseRepo> _warehouseRepo;
    private Warehouse _warehouse;

    [SetUp]
    public void When_An_Order_Is_Placed()
    {
        _warehouseRepo = new Mock<IWarehouseRepo>();

        _warehouse = new Warehouse() { Items = 20 };

        _order = new Order(_warehouseRepo.Object);
        _order.WarehouseBuilder = () => _warehouse; 
        _order.AddOrderItems(5);

    }

    [Test]
    public void Then_The_Order_Now_Has_5_Items()
    {
        Assert.That(_order.Items, Is.EqualTo(5));
    }

    [Test]
    public void Then_The_Warehouse_Now_Has_15_Items()
    {
        Assert.That(_warehouse.Items, Is.EqualTo(15));
    }
}

public interface IWarehouseRepo
{
    void Load(Warehouse warehouse);
}

其次是回调方法、代码和测试：(在回调中聪明)

 public class Order
{
    private readonly IWarehouseRepo _repo;
    public int Items { get; private set; }

    public Order(IWarehouseRepo repo)
    {
        _repo = repo;
    }

    public void AddOrderItems(int numberOfItems)
    {
        var warehouse = new Warehouse();
        _repo.Load(warehouse);
        warehouse.RemoveStock(numberOfItems);
        Items += numberOfItems;
    }
}

public class Warehouse
{
    public int Items { get; set; }

    public void RemoveStock(int numberOfItems)
    {
        Items -= numberOfItems;
    }
}

[TestFixture]
public class Given_A_Warehouse_With_20_Items
{
    private Order _order;
    private Mock<IWarehouseRepo> _warehouseRepo;
    private Warehouse _warehouse;

    [SetUp]
    public void When_An_Order_Is_Placed()
    {
        _warehouseRepo = new Mock<IWarehouseRepo>();
        _warehouseRepo.Setup(repo => repo.Load(It.IsAny<Warehouse>())).Callback<Warehouse>(warehouseArgument =>
            {
                warehouseArgument.Items = 20;
                _warehouse = warehouseArgument;
            }
        );

        _order = new Order(_warehouseRepo.Object);
        _order.AddOrderItems(5);
    }

    [Test]
    public void Then_The_Order_Now_Has_5_Items()
    {
        Assert.That(_order.Items, Is.EqualTo(5));
    }

    [Test]
    public void Then_The_Warehouse_Now_Has_15_Items()
    {
        Assert.That(_warehouse.Items, Is.EqualTo(15));
    }
}

public interface IWarehouseRepo
{
    void Load(Warehouse warehouse);
}

Answer 1

如果正确使用，添加公共状态以简化测试是一种有效的技术。同样，在保持生产代码完整的同时，使用复杂的测试也是完全有效的。两者都可能是错误的，所以第三种选择也是看你的设计。在现实中，你所选择的取决于各种因素。提防那些说出唯一真实方式的人。

公共国家

添加公共状态很好，因为它很简单，但是很糟糕，因为如果不针对代码编写自动化测试，那么它就不存在了。通常，当您掌握一些遗留代码并添加一些附加字段时，这是有意义的。如果您使这些只读，您也可以限制这些字段的范围。有趣的是，在软件中，这种技术没有得到应有的使用。在硬件领域，电路等都是实物运输的，测试部件仍然附在一起。这些从来没有用过，一旦装运。

复杂试验

这往往是你所看到的最常见的形式。杂乱无章的或复杂的测试，做任何事情，使测试工作。这里的好处是，设计至少不会为了测试而与公共字段妥协，但是正如您已经指出的，缺点是有些复杂和丑陋的测试。您可以通过使用SUT构建器或在执行过程中重构您的测试来抵消这一点，例如提取帮助以隐藏比较混乱的部分。如果这样做，至少可以保留干净的代码和更干净的测试的好处。

看设计

可悲的是，最不充分的使用，但会解决你的问题。测试很难写？那么你的设计就可以改进了。如果新代码的测试需要公共状态来使测试变得容易？那么你的设计就可以改进了。

您的示例

在你的情况下，这是合乎情理的，与较小的两个邪恶。使用回调的复杂测试将是我个人的建议。简单地说，当你权衡上面的优点和缺点时。是的，测试看起来很复杂，而且由于您使用的工具，它有一些相当粗糙的语法，但它并不是世界末日。

如果您真的不能改变加载仓库的方式，假设存在第三方依赖或其他原因，那么还有另一种选择。创建您自己的仓库存储库，它将隐藏命令方面并返回一个新的仓库实例。现在您将有一个查询，然后可以轻松地对其进行存根，并对上述问题进行分步处理。遗憾的是，这将引入一个新的组件，所以您需要权衡一下。如果您可以将组件更改为查询，我建议您首先这样做。

在我看来，Func并不是真正公开的国家。这不是一个领域。设计是错误的，这是一种相当新颖的做法。

Answer 2

两样都行吗。当我在这里走过我的思想过程时，请容忍我。这看起来更像是设计上的问题。我想起了我最近读到的一篇文章，内容是“新胶水”的顺序不应该与必须更新Warehouse实例或负责公开配置它(SRP)的方法相结合。我最初想添加一个新的依赖项，类似于工厂。

public interface IFactory<T> where T: class {
    T Create();
}

但是，尽管与之相反，这只是在课堂上添加了更多的黏液。我的想法集中在避免在SUT中引入额外的项目。

问题是，在您的示例中，SUT需要一种方法来创建仓库并加载它，但在保持自身相对精简的同时不负责。然后我开始了thinking...Whose的工作/责任是管理仓库.

IWarehouseRepo从我身上跳了出来，然后我想起了实体框架的IDbSet中看到的一个模式。

public interface IWarehouseRepo {
    Warehouse Create();
    void Load(Warehouse warehouse);
}

我无法摆脱这样一种感觉:我对这个问题想得太多了，结果结果是这样的

//My job is to provide a loaded warehouse to those who want one.
public interface IWarehouseProvider {
    Warehouse GetWarehouse();
}

这将提供一个已经装载的仓库供订单使用。这才是它真正想要的。

public class Order {
    private readonly IWarehouseProvider provider;

    public int Items { get; private set; }

    public Order(IWarehouseProvider provider) {
        this.provider = provider;
    }

    public void AddOrderItems(int numberOfItems) {
        //get a pre-loaded warehouse
        var warehouse = provider.GetWarehouse();
        warehouse.RemoveStock(numberOfItems);
        Items += numberOfItems;
    }
}

订单不应该关心仓库的创建或加载。它只是想要一个仓库来完成它的命令。为什么要把事情复杂化。我们有个很好的安排，现在你想粘起来了。(我离题)

[TestFixture]
public class Given_A_Warehouse_With_20_Items
{
    private Order _order;
    private Mock<IWarehouseProvider> _warehouseProvider;
    private Warehouse _warehouse;

    [SetUp]
    public void When_An_Order_Is_Placed() {
        _warehouse = new Warehouse() { Items = 20 };
        _warehouseProvider = new Mock<IWarehouseProvider>();
        _warehouseProvider.Setup(provider => provider.GetWarehouse()).Returns(_warehouse);

        _order = new Order(_warehouseProvider.Object);
        _order.AddOrderItems(5);
    }

    [Test]
    public void Then_The_Order_Now_Has_5_Items() {
        Assert.That(_order.Items, Is.EqualTo(5));
    }

    [Test]
    public void Then_The_Warehouse_Now_Has_15_Items() {
        Assert.That(_warehouse.Items, Is.EqualTo(15));
    }
}

对我来说，最终点燃灯泡的是你的测试。我决定把你想要测试的东西倒过来。

给一个有20个物品的仓库

当然，思想过程可能存在缺陷，但是Order类只是想要一个加载的仓库，而不关心如何创建或加载它。我可能在泥泞中旋转顶部，因为这看起来仍然像工厂的模式。

编辑。这样，潜在的提供者就可以如下所示

public class DefaultWarehouseProvider : IWarehouseProvder {
    private readonly IWarehouseRepo repo;
    public DefaultWarehouseProvider(IWarehouseRepo repo) {
        this.repo = repo;
    }
    public Warehouse GetWarehouse() {
        var warehouse = new Warehouse
        repo.Load(warehouse);
        return warehouse;
    }
}

这看起来像你以前的样子吗？是的，是的。现在的事情是，它被抽象到它自己的领域，允许它的依赖者继续他们的任务，而不关心香肠是如何制作的。您隔离/隔离您的约束，这样它们就不会四处传播它们的代码闻起来就会有疾病。:)