Architecture TDD:“；“仅测试”；方法

在这里寻找一些实用的建议，以及人们在类似情况下的经验

我们使用BDD/TDD sytle方法来构建软件（相当大/复杂的应用程序），最终结果是。。从业务需求、反映这些需求的单元测试和反映测试需求的代码派生的行为规范（给定/何时/然后样式）

然而，最近我们的测试部门已经开始运行集成测试，可以理解的是，他们希望使用我们（已经通过的）业务逻辑代码来设置和分解测试状态（而不是直接处理数据库）因为他们主要关心的是通过应用程序的UI进行测试，不想整天与数据库争论

问题是，一些实体存储库没有delete方法，因为还没有为这些方法表达业务需求。许多人有存档/恢复/备份等（可能有待完成的删除）

因此，现在我们有一个测试部门的删除要求（但与业务用户情景冲突）

所以。。。。我的问题是。。。如果我专门为测试部门添加方法。。。处理这些问题的最好方法是什么。我知道这在“TDD乌托邦”中通常被认为是不好的做法，但实际上，你是如何处理这种冲突的

我的第一个想法是使用命名

void TestOnly_Delete(Guid id){} 

…属性

[TestOnly]
void Delete(Guid id){}

。。。或编译器指令

#if TESTBUILD
void Delete(Guid id){}
#endif

因此，开发人员至少可以知道不调用TestOnly方法，最多不在生产构建中部署测试方法

。。。或者只是作弊并添加一个用户故事来管理它；-）

感谢您的任何经验或建议

---

提前感谢。

在我的代码中，我创建了一个子类：例如，如果我有一个

DataLayer

类，它拥有访问数据层的所有公共方法，那么我可能会使用

Test\u DataLayer

子类对其进行子类化，它继承了

数据层

的方法，并进一步实现了您可能需要的任何附加方法，如

删除

，其实现可以访问基类的内部或受保护的方法。

我通常以“仅测试”结束包含测试所需的任何mock/helper类的项目/库。在这个模拟库中添加必要的类/方法（生产代码中不包括这些类/方法）似乎很适合这个需求。如果您还没有这样一个库，并且不想创建一个库，那么我会标记——如果可能的话——内部方法，并且只将它们公开给测试框架。您没有指定平台，但我知道这在C#/.NET中是可能的，我经常使用此功能让我的测试访问库外不可用的方法

---

另一方面，我要说的是，测试人员与实际客户一样，也是您需求分析的一部分。就像我们有一些纯粹用于开发需求的需求一样，我们也有一些测试需求。正如您所发现的，诀窍在于以一种尽可能满足所有利益相关者需求的方式开发代码。当需求发生冲突时，我们会尽可能使用最好的折衷方案。在我看来，允许从仅测试库中删除是对客户数据安全需求（无删除）的合理折衷。

您首先要考虑的是添加此功能是否会增强或恶化当前的API？TDD中的一个典型场景是（最初）仅出于可测试性原因才需要类成员，但它符合所有正常的API设计准则，因此不会造成任何伤害（并且通常后来证明它也是生产代码中的一个有价值的补充）

如果这是真的，那么，如果你可以轻松地添加它，那就一定要添加它

然而，有时情况正好相反。在这种情况下，您必须抵制添加成员的冲动。但是，通常您可以遵循并打开API，以便其他人能够添加所需的功能

---

在您的情况下，最简单的解决方案可能只是确保有问题的类是未密封的，然后要求测试部门从这些类派生并自行实现功能。如果他们没有这个功能，那么你可以为他们做，同时仍然只保留子类测试。

这是一个有趣的问题。我有一些想法，但不确定这是否能解决你的问题

我将亲自创建一组明确的接口，继承您已有的实体接口，例如IIntTest_Customer:ICCustomer，并在其中定义delete方法。如果可能的话，尝试将所有这些接口放在单独的项目中，这样开发人员就不会从通常的项目中引用它们，从而避免意外使用它们。然后，测试部门将使用该特定的内部测试接口进行测试

---

要实现这一点，您可能必须重构当前代码，并更改实体以实现这些内部测试接口，而在继承层次结构中，所有引用基本接口的现有代码仍然可以工作

我永远不会在我的代码中添加delete或其他清理方法，只是为了支持自动测试

有很多选择，从智能事务管理到数据库的自动恢复