46｜RESTful Web Services（10）：伦敦学派与经典学派的测试节奏有何不同？
徐昊
你好，我是徐昊。今天我们继续使用 TDD 的方式实现 RESTful Web Services。
回顾架构愿景与任务列表
目前我们的架构愿景如下：
在继续拆分不同模块的任务之前，我们先回顾一下伦敦学派的做法：
按照功能需求与架构愿景，划分对象的角色和职责；
根据角色与职责，明确对象之间的交互；
按照调用栈（Call Stack）的顺序，自外向内依次实现不同的对象；
在实现的过程中，依照交互关系，使用测试替身替换所有与被实现对象直接关联的对象；
直到所有对象全部实现完成。
到目前为止，我们完成了第一层调用栈的测试。也就是以 ResourceServlet 为核心，测试驱动地实现了它与其他组件之间的交互。因为大量地使用测试替身（主要是 Stub），我们实际上围绕着 ResourceServlet 构建了一个抽象层。
如果我们继续沿着调用栈向内测试驱动，那么实际上就是为之前构建的抽象层提供了具体实现。因而，伦敦学派的过程就是一个从抽象到具体的测试驱动的过程。这也是为什么伦敦学派不惮于大量使用测试替身（甚至是 Mock）：具体实现是易变的，抽象是稳定的，因为它提炼了核心而忽略了细节。
如果抽象层构建合理，那么它就是稳定且不易改变的。重构和代码改写通常发生在实现层，合理的抽象可以屏蔽这些改变对于外界的影响。那么使用行为验证、mock、单元测试，也不会阻碍重构的进行。而随着调用栈向内，逐渐从抽象层走到具体实现的时候，具体的模块就不会再依赖额外的组件，那么单元测试自然变成状态验证的单元级别功能测试。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了RESTful Web Services中伦敦学派与经典学派的测试节奏差异。文章首先回顾了伦敦学派的做法，强调了从抽象到具体的测试驱动过程，并指出了伦敦学派与经典学派在测试节奏上的不同。接着，文章讨论了如何继续分解任务，包括对抽象层中其他使用到的组件加入任务列表，并提出了思考题，鼓励读者在留言区分享他们对任务的拆分。 文章突出了伦敦学派与经典学派的不同测试节奏，以及如何在实践中继续分解任务。读者可以从中了解到不同测试学派的特点，以及在实际开发中如何根据不同情况选择合适的测试节奏。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
《徐昊 · TDD 项目实战 70 讲》，新⼈⾸单¥98
立即购买
登录 后留言
全部留言(3)
- 最新
- 精选
忘川伦敦学派的抽象层划分难点 是依赖 现成的规约或者框架 也就是必须有一个被验证的约定在前 才能降低难点带来的影响 伦敦学派的深入调用栈 是依赖 后续对于测试用例的 不断整理重构 保证其结构不会随着太多而散乱2023-01-07归属地：上海1
大碗越外层的越像门面，主要负责编排，所以也更加抽象2022-09-08归属地：广东
Michael
我怎么觉得对于这种编排类型的组件的测试来说好像建立在抽象上的测试才是一个比较正确的做法呢？因为如果测试要测试的是意图而不是实现，那么我的理解就是你的编排型的组件必须得非常抽象，你才能做到测试意图呢？比如说，我要测试下单流程，可能下单的流程里还要支付，那现在我的下单依赖了支付组件，那也只能依赖抽象而不是具体的实现，这样我的单元测试可能就直接mock 抽象出来的interface PaymentProvider 而不用取关心具体的实现，这样以后即便我再怎么改我的下单的流程，只要业务上还需要支付我都可以不需要修改我的测试，这样不是挺好的么？当然了，你越接近具体实现，你的代码修改，你确实是要改的，但是你起码控制了你的修改面，不至于你实现细节的修改还要去修改上层的模块的测试。2022-06-21
收起评论
