如何平衡Framework / API Design和TDD

Question

我们正在构建一个将被其他开发人员使用的框架，现在我们已经使用了大量的TDD实践。我们到处都有接口，并且有很好的编写单元测试来模拟接口。

但是，我们现在已经达到了这样的程度，即输入类的某些属性/方法需要是内部的，并且我们的框架用户不可见（例如对象Id）。那么问题是我们不能将这些字段/方法放在接口上，因为接口没有描述可访问性。

我们可以：

1. 仍然在方法的第一行使用接口和upcast，但这似乎打败了接口的目的。
2. 使用类作为输入参数 - 打破所有应该是接口的TDD规则
3. 提供另一个在公共接口和内部接口之间进行转换的层

是否存在处理此问题的现有模式/方法？ TDD人员说应该做些什么？

Answer 1

首先，没有一般的TDD规则说一切都应该是一个接口。这是来自每个TDDer都没有实践的特定风格。见http://martinfowler.com/articles/mocksArentStubs.html

其次，您正在经历public vs. published的二分法。我们的团队通过引入API文档中显示的@Published注释来“解决”了这个问题。据我所知，Eclipse使用命名约定。不幸的是，我不知道这个问题的真正好解决方案。

Answer 2

您需要能够在模拟对象中复制这些内部方法。并以与真实对象称之为相同的方式调用它们。然后，将单元测试集中在依赖于您需要测试的私有方法的公共方法上。如果这些内部方法正在调用其他对象或进行大量工作，则可能需要重构您的设计。

祝你好运。

Answer 3

听起来你希望你的班级有dependency injection。也搜索stackoverflow。然后，您可以在构造函数中或通过setter选择此Id。

[1升