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

Question

因此，我和一位同事正在进行一场相当激烈的辩论。我们正在开始一个新项目，并尝试使用 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 会更容易。减少前端的实际代码。

希望我解释得足够好。

你们觉得怎么样？哪种方式更有意义？

Answer 1

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

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

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

更易于测试，以及更多类似 OO 的代码 =)

Answer 2

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

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

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

Answer 3

我更喜欢第二种方法，因为您所说的原因：您可以轻松模拟参数以进行测试。您使用依赖注入框架吗？如果没有，那么我建议您使用依赖注入原理来编程您的方法，以获得更加模块化且易于测试的代码。

我同意塞缪尔的观点，您需要尽可能避免使用静态方法，否则您会发现测试驱动它们非常困难。