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

Question

我看到在 Art of Unit Testing（Roy Osherove）中提倡添加 public 属性，以帮助获取和设置 SUT 使用的笨拙（或内部）collaborators/collaborations，并且我自己也使用了这种技术，效果很好。（我也看到了使用额外构造函数的类似方法）

同样，测试隔离框架（例如 Moq）可以提供替代方案，使用 Moq 回调可以帮助设置一个笨拙的 collaborator/collaboration。

我在这里经历的权衡是：

使用 public 字段将额外的项目引入 SUT，测试代码稍微更简洁

与

一个 SUT 没有被额外的项目弄得乱七八糟，使其可测试，并且测试代码稍微笨重（回调代码不是最漂亮的）。

在我的情况下，由于对什么是命令并且应该是查询的限制 - 一个可以 return 存根数据的查询，没有简单的方法来管理 SUT 中的协作（没有上述机制）

SUT 中的协作者更新了命令中通过引用传递的对象，这看起来像：（稍后在代码示例中重复）

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

编辑：我设计了一个存在设计问题的示例 - 仓库和订单过于亲密，应用程序服务可用于协调交互等。问题的要点是我几乎无法控制仓库被填充。我正在使用一个框架，该框架使用命令通过引用来混合对象。这就是问题所在，我知道，但不幸的是我被它限制了。所以这个问题的真正重点不是重新设计，而是纯粹是哪种方法、回调或 public 字段更可取，如果这是我们必须使用的全部。

下面的代码示例都是使用 Moq 和 NUnit 的工作示例。出于时间原因，我省略了添加应用程序服务来编排示例用例（这基本上是从合规仓库填写订单 - 基于 Fowler 的 Mocks aren't Stubs 示例）。此外，这两种方法都采用经典方法进行单元测试，断言状态而不是验证行为，这不是我的问题重点。

在继续之前，我有一个偏好，但我有兴趣看看其他人的建议或偏好。

所以首先是 public 属性方法、代码和测试：（聪明地使用 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

两者都不怎么样。当我在这里走过我的思考过程时，请耐心等待。这看起来更像是设计问题。我想起了最近读到的一篇文章，内容是 new 是胶水 ，其中 Order 不应该将自己与 new 的实例结合起来 Warehouse 或负责公开一些配置它的方法 (SRP)。我最初想添加一个新的依赖项，比如工厂。

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

但是尽管反对它，因为那只会在 class 中添加更多垃圾。我的想法集中在避免在 SUT 中引入额外的项目。

问题是，...根据您的示例，SUT 需要一种方法来创建仓库并加载它但不对其负责，同时保持其自身相对精简。然后我开始想...谁的job/responsibility来管理Warehouse...

IWarehouseRepo 突然出现在我面前，然后我想起了我在 Entity Framework 的 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));
    }
}

对我来说，最终点亮灯泡的是你的测试。我决定逆向处理您要测试的内容。

Given A Warehouse With 20 Items

当然思考过程可能有缺陷，但订单 class 只是想要一个加载的仓库，而不关心它是如何创建或加载的。我可能在泥泞中打陀螺，因为这对我来说仍然像工厂模式。

编辑。潜在的提供者可以是这样的

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;
    }
}

这看起来像你以前的样子吗？是的，是的。现在的问题是，它被抽象到自己的域中，允许它的依赖者继续他们的任务，而不用担心香肠是如何制作的。你 isolate/quarantine 你的限制，这样他们就不会四处传播他们的代码气味疾病。 :)

Answer 2

添加 public 状态以使测试更容易，如果使用得当，这是一种有效的技术。同样，面对复杂的测试，同时让生产代码保持完整也是完全有效的。两者都可能是错误的，所以第三种选择是也看看你的设计。实际上，您选择哪种取决于多种因素。提防任何说出唯一正确方法的人。

Public 州

添加 public 状态很好，因为它很容易，但很差，因为如果您不针对代码编写自动化测试，它就不会存在。当您掌握了一些遗留代码并且添加一些额外的字段不是什么大问题时，这通常是有意义的。如果您将这些设置为只读，您也可以限制这些字段的范围。有趣的是，在软件中，这种技术并没有得到应有的使用。在硬件、电路等领域中，实际装运时仍附有测试组件。这些在发货后从未使用过。

复杂测试

这往往是您看到的最常见的形式。杂乱或复杂的测试，无所不用其极以使测试正常工作。这里的好处是至少设计不会为了测试而与 public 字段妥协，但正如您所指出的那样，缺点是测试有些复杂和丑陋。您可以通过使用 SUT 构建器或简单地重构您的测试来抵消这一点，例如提取帮助程序以隐藏更混乱的部分。如果这样做，您至少可以保留干净的代码和更干净的测试的好处。

查看设计

遗憾的是，它未被充分利用，但可以解决您的问题。测试难写？然后你的设计可以做改进。如果新代码的测试需要 public 状态以便于测试？然后你的设计可以做改进。

你的例子

在你的情况下，采取两害相权取其轻的做法是有意义的。使用回调的复杂测试是我个人的建议。只要你权衡以上的利弊。是的，测试看起来很复杂，并且由于您使用的工具有一些相当粗糙的语法，但这不是世界末日。

如果假设存在第三方依赖或其他原因，您确实无法更改加载仓库的方式，则还有另一种选择。创建您自己的仓库存储库，它将隐藏命令方面和 return 一个新的仓库实例。您现在将有一个查询，然后您可以轻松地将其存根并避开上述问题。遗憾的是，这会引入一个新组件，因此您需要权衡一下。如果您可以将组件更改为查询，我建议您先这样做。

在我看来 Func 并不是真正的 public 状态。这不是一个领域。围绕设计错误的事实，这是一个相当新颖的 hack。

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

Should I use a callback or introduce a public field to aid with unit testing?

c#

tdd

nunit

unit-testing

moq

Public 州

复杂测试

查看设计