TDD 回炉重造

[EthanLin-TWer]

验证 TDD 的有效性
不跟人争论 TDD 是否有用，不在意别人的看法，不在意尝试说服别人。放下一切争论和心念，平静开始，不要想去超越别人，只超越自己。节省了情绪、争论、徘徊的时间；
每天25分钟

对待 TDD 的态度要更平和些。自己用，也要留意效率是不是确实提高了。江江江说的也有道理，「TDD 就是好，不好就是你用不好」。虽然我觉得真是这样的，但你都这么说那我们还聊个屁啊。TDD 的尴尬点可能在于，对于存疑的同学，你没有办法拿出一套数据，证明 TDD 时间省在哪里，各省多少。因为代码库现存复杂度、技术栈特性、测试设施都需要实际对待。

代领导说，how many keystroke left before you died！不过我就爱浪费时间，怎么着；大伟说，TDD 有很多衡量维度，有些维度不一定也无必要量化！那是，那不还是「具体情况具体分析」 嘛，我知道很好，但对我们项目就是用不上，别问为什么，我不一定能也无必要量化。一方面推广者要保持平和，多些实践，多些数据，本着我依照事实说，但爱不爱用随你的心态；一方面，我觉得也叫不醒一个装睡的人。

天地不仁。

验证 TDD 的有效性

我是说，如果真的要验证的话。方法应该是定义一个指标，并且比较在其他变量相同的情形下，TDD 较不 TDD 的效果。这个指标，视每个人理解不同，不过我的观点是，tasking+TDD+刻意练习可以使编码速度 极致加快。那么，如果我要论证 TDD 真的有用，别扯什么利于知识沟通共享，利于后续维护，减少了调试时间，这些也许都对，关键是都没有说服力。如果要提供数据，我会先只验证速度这个点。

• 速度：速度 = 工作总量 / 完成时间。工作总量有 tasking list 作为依据；完成时间自可以衡量。

像上面这样的说法，有一份响当当的数据就行了，什么话都不用说。如何获得响当当的数据？见最下面的扯淡部分。

那天跟耳朵聊，使用修佛法来类比练 TDD。我说，我接触到一些不做 TDD 的人，说法是感觉这个东西也没快多少，感觉掌握了思想就行了，但还是要具体情况具体分析。但你从来也没见 TA 们分析过，拿到代码都是本能地开始写实现，也不会列任务列表，也不会思考设计与实现，都是根据经验。我问妹子，佛看众生皆苦，而修行则是离苦得乐之道，但不以为然的人是很多的。佛陀想度众生，对这些人是什么态度？

妹子答：佛会承认因缘未到，不能度。但佛相信播种下去的种子，总可能会对人有益，总可能某个时刻让人意识到苦痛所在，进而发心修行。哪怕播种时完全看不到这时做此事的结果，都要去做。不求当下的回报。这是大心。

「須菩提！如恆河中所有沙數，如是沙等恆河於意云何？是諸恆河沙寧為多不？」
須菩提言：「甚多，世尊！但諸恆河尚多無數，何況其沙！」
「須菩提！我今實言告汝：若有善男子、善女人，以七寶滿爾所恆河沙數三千大千世界，以用布施，得福多不？」
須菩提言：「甚多，世尊！」
佛告須菩提：「若善男子、善女人，於此金剛般若波羅蜜經經中，乃至受持四句偈等，為他人說，而
此福德勝前福德。 - 《金刚经》

凡所有相，皆是虚妄；若见诸相非相，即见如来。你所看见的风景，是没有办法分享的，结果虽不能求，但播种、播好种，是更厉害的事情，可以倾向于此去做。可以利用诸相去做。

有的人觉得苦，想修行解脱；但有的人觉得不苦，生活这些幻相很好，很满足，每天都有美食旅游朋友圈。有的人觉得软件不能这么写下去，有的人不觉得，我每天坐着几个小时，写写文档，动动鼠标，慢慢地敲敲键盘，没有快捷键和 IDE 的日子也是那么美好，什么任务列表，什么 TDD，什么提前设计，我根本不觉得有任何问题。似乎感觉没有问题了也没有不对劲了。这样的麻木，也许才是我们说敏捷都要根据实际情况裁剪的原因吧。大家并不觉得有痛苦，也没发现 TDD 有多好。前者我没办法，后者，我觉得要做的话，就是拿出一份数据来说，做什么项目，人员技术什么水平，用和不用 TDD，速度快多少，代码质量又好多少。最好还是跟名人比，就是你别自己搞，没什么意思，大家也不服，跟名人搞，比如我们可以拿吴大师、汪大师、胡大师出来弄个 TDD 大赛，大家拿数据说话，扯这些有的没的。如果比出来，同一道企业级题目，吴大师不用 TDD 3小时，汪大师不用 TDD 2.9小时，胡大师使用 TDD 只要2小时，证明了 TDD 比不用 TDD 快33%，那什么根据项目实际情况裁剪不就是啪啪啪打脸了吗。对吧，TDD 更快，有更快的方法，你为什么不用呢？

然而我并不打算去证明这些。我只想自己先练好，日后再说。任务分解，红绿循环，刻意练习，应该是正确的路线。

卧槽，为了引用一些佛家经典，google 到的这都什么东西，故事整得这么吓人。当即决定不再说了。

[kind-hearted]

楼主，赞一个。想问下，如何在前端添加测试保证提交后端的数据结构是合法的？重构时，经常会在这一块出问题，有什么好的做法呢？这块涉及到实际的提交，单元测试保证不了，自动化测试要覆盖到的话工作量偏大。

[JimmyLv]

@chinafootballyu API contact testing 即契约测试是一种很好的方式，😉

[kind-hearted]

@JimmyLv 感谢回答。其实问题主要是针对后端API没有改变，仅仅只是前端进行重构（入参的获取、校验、传入存在重复代码之类），这个时候极有可能导致参数和原来的不一致，这种情况有没有好的办法进行测试，保证入参不变。

[EthanLin-TWer]

如果是后端 API 经常改变的话，API 契约测试就是不错的方式，然后在单元测试中只需按契约测试中声明好的数据结构进行存取即可。

如果是后端 API 没变，是在聊入参数据结构的话：不知你能否举个具体的例子。按理来说，重构是否成功的唯一依据是测试是否依然都是通过的。如果你在实现代码中改变了入参获取方式、校验等其他问题，可能会导致测试失败。具体可能需要看到例子以后才能展开。举个例子：

    it('should display pre-selected machine\'s title', () => {
      const wrapper = setup({
        solutionConfig: {
          server: {
            '9532AC1': {
              label: 'Lenovo Converged HX 7000 Series',
              quantity: 1
            }
          },
          storage: {
            '8871AC1': {
              label: 'Lenovo Converged HX 8000 Series',
              quantity: 1
            }
          }
        }
      })
      const lv5Title = wrapper.find(`.${className}__lv5_title`)

      assert.equal(lv5Title.text(), 'Lenovo Converged HX 7000 Series')
    })

我传入的 solutionConfig 就是真实 API 会返回的数据。假设后端 API 不变，契约测试没挂，那么这个数据结构应该也是不变的。那么我只要保证我的 assert.equal() 在重构后依然通过即可，至于重构时你是否对入参做了什么操作，无所谓，测试通过即可。

[JimmyLv]

重构是否成功的唯一依据是测试是否依然都是通过的。

重构不一定要有测试，所以我要实名反对你这句话😋

[JimmyLv]

@chinafootballyu 契约测试不仅仅是前端对于后端的要求啦，既然名为契约就是说两者都有约束作用。

具体来说，契约两端分别是provider和consumer，前端取数据的时候是作为consumer，也就是说后端也可以有自己的契约测试，当前端提交数据的时候则是作为provider的。

而具体的契约文件往往有一个存放中心(比如pact broker)，一方上传，另一方取来验证。

[kind-hearted]

多谢两位~

[EthanLin-TWer]

来，大声地说出你的名字！

[EthanLin-TWer]

https://blog.linesh.tw/#/post/2017-06-08-tdd-series-1-rethink.md

有博客就是好。