022 TDD和Stack Overflow的专家开发者

《黑色敏捷书》简体中文版可在这里购买：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail （《敏捷思维》在背景中播放） Vanilla：呃，你就是Lecter先生吧？ Hannibai：Lecter博士。叫我Hannibai就好了。 Vanilla：博士先生，TDD是如何运作的呢，我们可以尝试使用吗？ Hannibai：流程似乎非常简单，和开发者熟悉的传统工作流步骤恰好相反。目前我对这样工作的效果比较关注。此外，我还很关注这种工作流的价值。 Vanilla：呃，是的。回到工作流上，你了解这些步骤吗？ Hannibai：工作流似乎是，第一步，研究产品代码，发现你想变动的地方。 Vanilla：没错，正是。 Hannibai：第二步，决定具体的设计。考虑是新增方法，还是直接修改已有的代码。 Vanilla：然后呢？关键的步骤是？ Hannibai：是的，Clarice。第三步是—— Vanilla：呃，Clarice？ Hannibai：请让我继续说，第三步是很有趣的一步。我们并不是直接变动代码，相反，我们会写出—— Vanilla：（很激动地）测试代码！ Hannibai：没错，为变动代码所写的微测试。有时候，我们需要改变一个已有的接口，或者写一个新的对象和函数，然后用测试来驱动调用已有代码里的新接口。确定微测试的规格，是实现下一步功能的最简单方法。 Vanilla：（很夸张地）然后呢？ Hannibal：第四步，运行微测试，查看是否能通过。观察红色的错误提示。你看见是哪个了没有（严肃地），Clarice？ Vanilla：啊哈…… Hannibal：也就是说，微测试的确有可能通不过。但你知道吗，Clarice？ Vanilla：啊…… Hannibal: (angrily) There is no sense in writing automated tests that cannot indeed fail! Hannibal：（有些生气的样子）如果所写的微测试100%会通过的话，就没必要写啦！ Vanilla True Vanilla：确实如此。 Hannibal：还有第二个原因，你知道不？在我们添加或是修改了产品代码之后，可以观察测试结果由失败到通过的改变。 第三个原因，先写测试，能让你从代码调用者的角度思考。调用代码的人才是新功能的使用者。这不像你自己独自吃掉一个蛋奶酥，很快当。学会用良好的方式编写接口，不可能像吃蛋奶酥一样一下子就好。这一切是一种更高明的代码编写方法。 Vanilla：（觉得尴尬和唐突）呃，好的。听起来挺不错的。我们可以开始了吗？ Hannibal：没错。我们把故事分成两部分，一部分要使用TDD，另一部分不用TDD。我们用计时器来测量每个组所花费的精力。 Vanilla：好的，为什么这样做呢？ Hannibal：（清了清喉咙）啊，亲爱的Clarice，你看见了没？我们必须了解TDD的确是能节省开发和测试环节时间的。不然何必使用TDD呢？ Vanilla：是的，有道理。 Hannibal：计时开始，大家行动吧！ (Typing sound.  Music.  Time passes. Ding.) （打字的声音。音乐。时间过去了。叮。） Vanilla：测试已通过。 […]

The post 022 TDD和Stack Overflow的专家开发者 first appeared on Agile Thoughts.