Question

[TDD新手]

我有一辆具有Color和Brand属性的Car。

在TDD中测试构造函数是否设置了这些属性是否有意义？或者我等待测试（并实施）直到我需要它？

那么，我是否要构建这样的测试：

（C＃）

public class CarTests
{
  public void Constructor_Should_Set_Color()
  {
    var car = new Car("Green", "Volvo");

    Assert.Equals(car.Color, "Green");
  }
}

或者我等到我有一个用例场景，例如，我必须从使用构造函数构建的列表中过滤掉所有绿色汽车，这会因为汽车的颜色为null而失败？

直接测试构造函数真的有意义吗？怎么样Equals（）？

Answer 1

理想情况下，我认为，在您需要之前，您甚至不会拥有 Color属性。此时，您可能只使用setter，或者可以将其添加到构造函数中，或者添加新的构造函数。第二个选项使您处于具有两个（或更多）构造函数的状态 - 您可能会发现它很有用;在许多情况下（对于测试和“常规”代码），您可能不会关注汽车的颜色。并且正在测试你的设计。

Answer 2

这似乎取决于开发人员/开发人员团队的环境和偏好，就像是否在一个测试方法中有几个不同的断言一样。

虽然纯粹主义者可能希望获得接近100％的测试覆盖率，但也有开发人员只测试非平凡的东西。这两个极端之间的界限很模糊。

Answer 3

如果您实际上正在进行TDD，那么在测试需要它们存在之前，您将不会拥有颜色和品牌属性。

该测试可能不应该像您的构造函数测试，而是测试关注Color或Brand的其他内容。

Answer 4

如果它们不太复杂，我通常不会打扰测试构造函数和Equals。如果它们变得更复杂或者我遇到了错误，那么我会添加测试。虽然这可能是一个信号，表明你的班级太复杂而且需要重构，只有你的班级受到安全检测网的保护才能安全地完成。

从测试驱动的角度来看，你可能不会从测试构造函数开始。由于某些场景有用并且应该在该环境中进行测试，因此需要使用类或方法。

Answer 5

这为我大部分前TDD思维方式提出了一个有趣的难题。

传统上，我对OOP的解释表明你的汽车类应代表现实。这意味着汽车在创建时应该获得它的颜色，除非通过一些重新塑造汽车的“特殊”方法，然后只有当您的业务逻辑允许时才能更改它。

我认为TDD的答案是你不能模拟现实，你应该在应用程序中模拟允许的行为变化范围。也许这款车是在线订购应用程序中的假想未来汽车，或者是可以无缝改变颜色的游戏中的模型。无论如何，上面的Paeleo-OOP方法在TDD哲学中是无效的。

要尝试直接回答您的问题，我会说应该使用符合您业务规则的最严格的语义设置color属性。如果您当前已知的任何规格项目要求汽车能够动态更改其颜色，请将其编码为可设置属性。否则，它属于构造函数。一旦有人决定在项目的下一次迭代中修改规范，请准备好撤销此决定。

TDD：测试构造函数设置属性是否有意义？

5 个答案: