在这里寻找一些实用的建议以及人们在类似情况下的任何经验。
我们使用 BDD/TDD 风格方法来构建我们的软件(相当大/复杂的应用程序)最终结果是.. 行为规范(Given/When/Then 风格)源自业务需求、反射(reflect)这些的单元测试和反射(reflect)这些的代码测试的要求。
但是最近我们的测试部门已经开始运行集成测试了，可以理解的是他们想使用我们(已经通过的)业务逻辑代码来设置和拆除测试状态(而不是直接与数据库打交道)，因为他们主要关心通过应用程序的 UI 进行测试，并且不想花费一整天的时间来处理数据库。
问题是，一些实体存储库没有删除方法，因为还没有针对这些表示的业务需求。许多都有存档/恢复/备份等(并且可能在积压中删除待处理)。
所以现在我们有一个测试部门。删除要求(但与业务用户故事冲突)
所以......我的问题是......如果我要专门为测试部门添加方法......处理这些的最佳方法是什么。我知道这在“TDD Utopia”中通常被认为是不好的做法，但实际上，您是如何处理这种冲突的？
我的第一个想法是使用命名...
void TestOnly_Delete(Guid id){}
...属性...
[TestOnly]
void Delete(Guid id){}
...或编译器指令...
#if TESTBUILD
void Delete(Guid id){}
#endif
因此，至少，开发人员可以知道不要调用 TestOnly 方法，并且最多不会在生产版本中部署测试方法。
...或者只是作弊并添加一个用户故事来管理它;-)
任何经验或建议，不胜感激？
提前致谢。
最佳答案
您首先应该关心的是添加此功能会增强还是恶化当前的 API？ TDD 中的一个典型场景是(最初)仅出于可测试性原因才需要类成员，但它符合所有正常的 API 设计指南，因此它没有任何危害(并且通常随后证明是生产代码中有值(value)的补充，如好)。
如果这是真的，那么如果您可以轻松添加它，请务必添加它。
然而，有时情况正好相反。在这种情况下，您必须抵制添加成员的冲动。但是，通常您可以关注 Open/Closed Principle并开放您的 API，以便其他人能够添加所需的功能。 Testability is really just another word for the Open/Closed Principle .
在您的情况下，最简单的解决方案可能只是确保有问题的类是未密封的，然后要求测试部门从这些类派生并自己实现功能。如果他们没有这种能力，那么你可以为他们做这件事，同时仍然保持子类仅供测试。
关于architecture - TDD: "Test Only"方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2295965/