• TDD,从顶向下测试


    我们首先根据最上面的模块,我们称之为A,写好测试用例,却发现我们没有办法在几分钟,甚至半个小时内,去通过这个测试。因为我们需要一些其他的模块,如B和C,我们需要把它们put together。那么我们的开发就陷入了一种反敏捷的方式,我们没有办法得到及时的反馈。但是不是这样的。我们大致已经知道了要有B和C,那么下一步是什么。是在A中描述B和C的接口和功能,并且试图把他们put together,还是想写B和C的测试用例呢?

    我所推介的是前者。那么怎么回答这个难题:我们不能得到关于B和C的反馈,这不是敏捷的。事实上,A作为B和C的客户,已经大致描述了B和C的接口和功能,而且,我们在验证,如何让B和C恰好做它们要做的事情,不多也不少,而且当它们put together的时候,它们可以完成A要的那些工作,不多也不少。那么这个就是关于设计的反馈,如果不从A的角度来思考B和C的功能,那么就有可能造成B和C的功能的泛滥和缺失。

    而在A中描述了我们对B和C的意图之后,下一步是什么?

    我们应该用TDD的方式来开发B和C,让它们满足A的功能和接口通过测试。

  • 相关阅读:
    SQL结构化查询语言
    数据库主外键
    SQL数据库数据类型详解
    注释和特殊符号
    文本装饰
    列表样式
    网页背景
    SQL数据库数据类型详解
    数据库主外键
    Update 语句
  • 原文地址:https://www.cnblogs.com/zhengwenwei/p/2541279.html
Copyright © 2020-2023  润新知