22｜DI Container（10）：怎样将大粒度的测试重构为等效的小粒度测试代码？

2022-04-26 徐昊

《徐昊 · TDD 项目实战 70 讲》

课程介绍



讲述：李辰洋

时长:大小1.30M



你好，我是徐昊。今天我们继续使用 TDD 的方式实现注入依赖容器。
回顾代码与任务列表到目前为止，我们的代码是这样的：
ContextConfig.java:package geektime.tdd.di;import java.util.*;import static java.util.List.of;public class ContextConfig {    private Map<Class<?>, ComponentProvider<?>> providers = new HashMap<>();        public <Type> void bind(Class<Type> type, Type instance) {        providers.put(type, new ComponentProvider<Type>() {            @Override          ...



展开全文

精选留言

张铁林
置顶
2022-04-29
https://github.com/vfbiby/tdd-di-container/tree/main/doc 在这下面有每一章的“心法”，照着练，就不用看视频了，全程尽量跟着老师的步骤来。
奇小易
2022-06-03
Q: 如何发现坏味道？本文出现两个坏味道，一个是一个测试类的上下文中存在粒度(测试范围)不同的测试。另一个是测试本身不具有文档的性质，不好理解。据此可知，好的测试需要具备文档化的特点，好的测试需要在同一上下文保持一致的粒度，保持一致的命名思路。这些良好测试的特点就是用于识别坏味道的指导方针。
展开
davix
2022-05-25
老師可否講講測試粒度的選擇、組織？TDD適不適合測試金字塔各個層？縱然大粒度測試應該少，但前提是大粒度測試的低效（如難維護的依賴，易出錯等）。如果像本項目這樣的純內存裡的測試，大粒度不是更合適嗎？更有利於內部的重構。
aoe
2022-05-04
测试变文档 - 从文档角度优化测试 - 使用 @Nested 将功能分组 - 测试天然不是文档，而是你实现过程的记录 - 对测试进行足够提取和刻意的组织后才能变成真正的文档
展开
临风
2022-05-02
代码坏味道就是你看了代码觉得不好理解的地方，本质就是为了提高代码的可维护性和可读性。之前我写代码的时候容易考虑很多，导致代码过度设计。后面学习代码重构手法之后，配合上TDD的使用，就有充足信心，减少甚至不考虑未来的拓展性问题。因为将来代码改动时，你可以通过重构的手法，使其适应改动的方向，再进行代码功能的增添，使代码能一直保持很高的可读性。另外对于测试代码的重构，老师的“测试天然表现的是开发实现的逻辑，测试天然不是文档”的观点让我印象深刻。之前也听过，你不要让别人通过逐行看代码来理解代码逻辑，而是要通过测试用例来告诉别人你的代码逻辑和功能，直到完成测试的重构才彻底明白了这一观点的由来。上次作业完成的时候，和老师的实现略有不同，经过老师的提示后，进行了重构。期间充分体会到TDD的好处，由于测试的充分覆盖，你的每个功能点都不用害怕代码的重构会不小心改坏了。看着简洁的代码，竟莫名有点小成就感。最后有个问题想问老师，这个container是因为只有自己一个人写，可以随心所欲。实际项目中，如何才能在缺少测试用例的情况下进行一定的代码重构呢？老师会建议直接复用代码，还是有其它好的方法呢？ https://github.com/lenwind/TDD-Learn
展开
张铁林
2022-04-29
https://github.com/vfbiby/tdd-di-container 我来贴一下代码，没有每一步小的做提交，主要是为了方便回滚到上一课，再来练习。