派生、组合、构造函数、接口和TDD

Question

当开发TDD时，您的对象会随着代码的发展而“增长”。首先，它们只包含一些功能，然后添加新功能。基本上可以通过组合和/或继承来完成。

同时，您几乎总是使用接口(用于测试和生产代码)来确保低耦合、依赖反转、依赖注入和模拟。

你是怎么处理这个的？

我的意思是，例如:您已经创建了一个类，现在它必须包含一个新属性(例如，一个人现在可以拥有一封电子邮件)。该怎么办呢？

• 修改类，添加新属性:然后必须添加新的构造函数。但是，如果修改现有的构造函数，则必须重构所涉及的所有测试，而不仅仅是产品代码。您可以尝试在添加新属性时保留所有构造函数，但最终会变得无用、过时(只因为测试而存在)，具有“构造函数调用另一个构造函数”(或使用某种类型的“工厂”)的复杂逻辑。
• 派生类:这是OCP的更多编译器。但是，如果您使用很小的步骤创建了一个真正的TDD，如果您总是从一个非常简单的类开始派生，那么您将以一个非常复杂和不相关的继承结束。另外，我们认为你必须只测试公开的会员。因此，随着基类受到保护，必须重构测试才能访问公共测试。
• 撰写:构造函数没有问题，但并不总是一个好的解决方案。至于我们目前的例子。

在某种程度上，界面也会发生类似的事情。

因此，随着代码的增长，构造函数--接口--必须进化。我心里有三个戒律：

• 您应该避免重构测试。
• 生产代码不能保留“只用于测试的代码”(即构造函数)。
• ISP声明使用特定的接口。随着代码的增长，其中许多类变得不必要，因为它们只用于测试(即模拟)类，在许多情况下，这些类应该受到保护或私有。

所以就像我说的..。如何在开发TDD的同时管理所有这些？我知道这是一个需要长时间回答的问题，所以，如果你能参考一些好的文章或资源

Answer 1

更改测试是可以的，

你所描述的(人现在有一封电子邮件)是对规格的改变。单元测试应该是您的规范，所以在引入新数据时必须更改它们是正常的。

这种测试的脆弱性是对质量的一种交换，是一种必要的邪恶。

不要过度设计

通过尝试应用OCP、继承和组合来添加一个字段，您只会使事情变得更加复杂。正如您所指出的，它仅仅是为了测试而导致产生代码的不正常，而且您还必须修改测试。

如果要在现有的一系列行为中添加新的行为，OCP可能是好的，但这里的情况并非如此。

使更改更易于管理

有一些策略可以使您的测试对小的更改更具抵抗力，但是它们主要是在测试级别实现的，而不是在生产代码中实现的。此外，如果您经常在测试中寻找重复，例如在TDD周期的重构步骤中，那么这方面的机会就很容易发现。

其中之一是将您的“系统被测试”创建封装到一个工厂法中，并在每个测试中调用它而不是普通的构造函数。使其大多数参数具有默认值可选。这将允许您在一个地方进行更改(例如添加电子邮件字段)，所有测试都将从中受益。这并不能使您免于修改测试套件，但您只需要在一个地方进行。