Chr*_*isV 14 architecture tdd bdd integration-testing naming-conventions
在这里寻找一些实用的建议以及人们在类似情况下的任何经验.
我们使用BDD/TDD sytle方法来构建我们的软件(相当大/复杂的应用程序)最终结果是......从业务需求派生的行为规范(Given/When/Then style),反映这些的单元测试和反映的代码测试的要求.
但是,最近我们的测试部门已经开始运行集成测试,可以理解的是他们希望使用我们(已经通过的)业务逻辑代码来建立和拆除测试状态(而不是直接处理数据库),因为他们主要关注通过应用程序的UI进行测试,不想花一整天的时间来争论数据库.
问题是,某些实体存储库没有删除方法,因为还没有针对这些方法表达业务需求.许多人有存档/恢复/备份等(并且可能在待办事项上有删除待处理).
所以现在我们有一个测试部门.删除要求(但与业务用户故事冲突的要求)
所以......我的问题是......如果我要为测试部门专门添加方法......那么处理这些方法的最佳方法是什么.我知道这在"TDD乌托邦"中通常被认为是不好的做法,但实际上,你是如何处理这种冲突的？
我的第一个想法是使用命名...
void TestOnly_Delete(Guid id){}
... ...属性
[TestOnly]
void Delete(Guid id){}
......或编译器指令......
#if TESTBUILD
void Delete(Guid id){}
#endif
因此,开发人员至少可以知道不要调用TestOnly方法,并且最多不会在生产版本中部署测试方法.
...或者只是作弊并添加一个用户故事来管理它;-)
任何经验或建议感激不尽？
提前致谢.
您首先关心的应该是添加此功能是否会增强或恶化当前的 API？TDD 中的一个典型场景是，类成员（最初）仅出于可测试性的原因而需要，但它符合所有正常的 API 设计准则，因此它不会造成任何损害（并且通常随后会成为生产代码中有价值的添加，因为出色地）。
如果这是真的，那么如果您可以轻松地添加它，请务必添加它。
然而，有时情况恰恰相反。在这种情况下，您必须克制住添加会员的冲动。但是，通常您可以遵循开放/封闭原则并开放您的 API，以便其他人能够添加所需的功能。可测试性实际上只是开放/封闭原则的另一种说法。
对于您的情况，最简单的解决方案可能只是确保相关类未密封，然后要求测试部门从这些类派生并自行实现功能。如果他们没有这种能力，那么您可以为他们做这件事，同时仍然保持子类仅用于测试。