BDD/TDD 以棘手的方式模拟数据答案

【问题标题】：BDD/TDD mocking data the tricky wayBDD/TDD 以棘手的方式模拟数据
【发布时间】：2011-01-09 18:23:25
【问题描述】：

所以我和一位同事正在进行一场相当激烈的辩论。我们正在开始一个新项目，我们正在尝试使用 BDD。我们都是新手，并不完全了解应该使用哪些做法。我们已经编写了一些规范，现在正在实施代码。由于有很多数据库交互，事情变得非常棘手。我们被困在如何模拟我们的数据上。我们正在使用的方法需要我们模拟我们的方法而不是我们的数据。如果我用代码告诉你，那是最简单的......

public static void AssignLeadToDistributor(int leadId, int distributorId)
{
    Lead lead = GetById(leadId);
    lead.DistributorId = distributorId;
    Save(lead);
}

基本上，我们必须重写 GetById() 和 Save() 以返回模拟数据以供我们测试。这样做似乎更有意义：

public static void AssignLeadToDistributor(Lead lead, Distributor distributor)
{
   lead.DistributorId = distirbutor.Id;
}

然后我们就可以模拟我们的对象了。

显然第二种方法更容易测试。然而，争论是我们不希望在前端代码中获取新的潜在客户和分销商对象，因为只传递对象的 id 会更容易。减少我们前端的实际代码。

希望我解释得足够好。

你们怎么看？哪种方式更有意义？

【问题讨论】：

嗯，当然，二元决策图很棒，但它们并不是最后一代的东西，它会让我们所知道的一切都过时......哦，等等，没关系。

标签： unit-testing tdd mocking bdd specifications

【解决方案1】：

我认为您遇到的最大问题是因为您使用了公共静态函数（这在 OO 语言中通常是一件坏事）。

我建议将此函数移至 Lead 对象，例如

public AssignDistributor(int distributorId) {
   this.DistributorId = distributorId;
   this.Save();
}

更容易测试，更类似于 OO 的代码 =)

【讨论】：

【解决方案2】：

我更喜欢第二种方法，因为您所说的原因：您可以轻松地模拟参数以进行测试。你在使用依赖注入框架吗？如果不是，那么我建议您使用依赖注入原则对您的方法进行编程，以获得更多模块化和易于测试的代码。

我同意 Samuel 的观点，即您需要尽可能避免使用静态方法，否则您会发现很难测试它们。

【讨论】：

【解决方案3】：

我们在 BDD 规范（可执行故事）中所做的是根本不模拟数据库，而是使用内存中的数据库（在我们的例子中是 SQLite）。

此外，我们会在任何场景运行之前初始化容器。这是因为我们希望我们的 BDD 规范尽可能地模仿现实世界，同时仍然具有普通单元测试的速度。

通过以这种方式定义我们的 BDD 规范，我们发现对单元测试和集成测试的需求减少了，并且提高了生产力和可理解性（尽管非常主观，因为您无法真正衡量这些指标）。

【讨论】：

这是我们最终选择的路线。效果很好。
Super :-) 我们也越来越欣赏这种方法。