从新手到TDD的一个非常具体的问题:
我将我的测试和我的应用程序分成不同的包.因此,我的大多数app方法必须公开才能访问它们.随着我的进步,很明显某些方法可能变得私有,但如果我做出改变,访问它们的测试将无法工作.我错过了一步,或做错了什么,或者这只是TDD的一次垮台？
Jos*_*osh 18
这不是TDD的垮台,而是一种测试方法,认为您需要测试每个属性和每个方法.事实上,在测试时你不应该关心私有方法,因为它们只应该存在以便于API的某些公共部分.
永远不要为了测试目的而将某些内容从私人改为公
您应该尝试仅验证公开可见的行为.其余的是实现细节,您特别希望避免测试它们.TDD旨在为您提供一组测试,使您可以轻松更改实施细节,而不会破坏测试(更改行为).
假设我有一个类型:MyClass我想测试该DoStuff方法.我所关心的是该DoStuff方法做了一些有意义的事情并返回了预期的结果.它可能会调用一百个私有方法来达到这一点,但我并不关心该方法的消费者.
您没有指定使用的语言,但在大多数语言中,您可以将测试放在具有更多特权访问权限的方式中.例如,在Java中,测试可以位于同一个包中,实际的类文件位于不同的目录中,因此它与生产代码分开.
但是,当你进行真正的TDD时,测试正在推动类设计,所以如果你有一个方法只是为了测试一些功能的子集,你可能(并不总是)做错了,你应该看看技术喜欢依赖注入和模拟以更好地指导您的设计.
这就是古老的说法,"TDD与设计有关",经常出现.一个拥有太多公共方法的课程可能有太多的责任 - 而且你试驾它的事实只会暴露出来; 它不会导致问题.
当你发现自己处于这种情况时,最好的解决方案是经常找到可以提取到新类("sprout类")的公共方法的一些子集,然后给你的原始类提供一个sprouted类的实例变量.公共方法值得在新类中公开,但它们现在 - 就原始类的API而言 - 私有.而且你现在更好地坚持SRP,更松散的耦合,更低的凝聚力 - 更好的设计.
所有这些都是因为TDD暴露了你班级的特征,否则这些特征会在雷达下滑动. TDD是关于设计的.