在我的记忆中,大多数人告诉我,我应该从上到下进行设计.如果我想实现一个网页,我应该在纸上绘制或绘制这个页面,然后将其分成一些功能.对于每个功能,我尝试设计外部API,并分别实现它们的内部.

但是在TDD中,他们说我应该考虑一个非常小的功能(一种方法？),首先编写测试,失败,实现它并通过测试.编写它们是最后一步.我无法想象它如何获得良好的API.

最奇怪的是,他们说TDD不仅是单元测试,还有功能测试.我认为这意味着自上而下.如果存在由方法B,C和D组成的功能A.由于TDD,我首先为A编写功能测试.但是…… B,C,D都是未实现的.我应该使用三个存根吗？如果B依赖于其他三种方法？

我用TDD写了一些小程序.但是当我使用GUI攻击应用程序时,我陷入困境.

最佳答案 我一直在为我的rails项目大量编写rspec测试,在代码/测试之间保持大约1：1.6的比例.我从来没有真正解决过先写什么或者依赖什么的问题.如果我想写的方法A由B和C组成,那么我将首先使用正确的测试来实现B和C.对我来说,只要测试是好的和精确的,序列就不那么重要了.

所以,我并没有像你描述的那样使用存根,但只有当功能已经存在并且我只是想绕过/绕过它时.

顺便说一句,它被认为是一种自上而下的方法.这是Rspec Book的摘录：

If you ask experienced software
delivery folks why they run a project
like that, front-loading it with all
the planning and analysis, then getting into the detailed design and
programming, and only really integrating and testing it at the end, they
will gaze into the distance, looking
older than their years, and patiently
explain that this is to mitigate
against the exponential cost of
change—the principle that introducing
a change or discovering a defect
becomes exponentially more expensive
the later you discover it. The
top-down approach seems the only
sensible way to hedge against the
possibility of discovering a defect
late in the day.