TDD是顶部还是底部设计？

发布时间：2020-12-14 04:50:51 所属栏目：百科来源：网络整理

导读：在我的记忆中,大多数人告诉我,我应该从上到下进行设计.如果我想实现一个网页,我应该在纸上绘制或绘制这个页面,然后将其分成一些功能.对于每个功能,我尝试设计外部API,并分别实现它们的内部. 但是在TDD中,他们说我应该考虑一个非常小的功能(一种方法？),首先

在我的记忆中,大多数人告诉我,我应该从上到下进行设计.如果我想实现一个网页,我应该在纸上绘制或绘制这个页面,然后将其分成一些功能.对于每个功能,我尝试设计外部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.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!