020 TDD破坏者

Vanilla Pop：看见了没？在写产品代码前先写一小段测试，一切都会非常完美。 Joe：我不知道，我觉得思维上还不太适应这种向后工作的方式。 Vanilla：但这样操作对你来说是很容易的，对吧？ Joe：那是自然！我已经从这儿学到了这套方法！ Vanilla：（声音听起来不太确定）呃，我们继续结对编程吧。 Joe：你知道吗，我感觉你非常担心的样子。而且，我需要独自工作，不然我会感觉自尊心受伤了。 Vanilla：好的，你都这样说了，那行。 （时间一点点过去了，音乐声配上打字的键盘敲击声。在这天结束的时候，关灯时开关发出了响声，门也砰地一声合上了。） 第二天 Vanilla：我们看看这些测试吧。 Joe：来吧！你会喜欢这些测试的，我还做了一些调整。 Vanilla：呃？我点击测试按钮的时候，停顿了一下，而且…… Joe：（很自豪地说着）弹出了一个对话框！ Vanilla：呃…… Joe：是的，这个对话框会询问用户希望往测试中传递什么样的疯狂参数。这样，我就可以用一个测试来取代你的4个测试了。 Vanilla：啊……现在测试时，我需要进行互动才能—— Joe：很厉害不是吗？如果需要进行调试，就都全部准备好了！ Vanilla：但是Joe，我并不希望与微测试进行互动。有时候，会有数千个微测试，与它们互动时间上是没法操作的。只需要点击一下，全部的微测试就应该都开始运行了。 Joe：（心碎了）噢！明白了，我来处理吧。 （过了一段时间） Vanilla：为什么今天的测试运行报告比昨天少了一些测试呢？ Joe：有些测试不知怎么回事，一直通不过，所以我禁用了一些测试？ Vanilla：等一下！你的意思是，我每天都在增加测试，而你开始工作的头几天，你就直接把测试数量减下去了？ Joe：这么说，是的。你的测试在我调整了代码之后就不起作用了。 Vanilla：是吗？你应该维护已经提交的测试，不然我们就只能原地踏步。 Joe：但是你把测试设计得太不灵活了。你得同意使用对话框，让用户手动输入测试参数的方法，就像我之前实施的那样—— Vanilla：但是Joe，每个微测试都是针对单一的情景设计的，仅仅就一个情景。这样测试才简单易懂，而且容易维护。 Joe：那如果测试没通过，你希望我怎样处置呢？打开对话框，没错对话框很有用！ Vanilla：你需要维护测试，Joe。 Joe：可是我怎样知道哪一部分出了问题呢？是测试还是我的代码？ Vanilla：测试的结果会提醒你有情况。这时你需要调查分析，并做出判断：是自己的代码出了问题，还是测试需要更新。 解说：Vanilla Pop正在让组员开始学习TDD。第一个错误，就在于他没有让Joe和他一起结对编程。教育系统培养的开发者习惯自己独立完成任务。而且，很多开发者习惯花费几个小时，自己面对着电脑挣扎，而不愿意与其他同行争执和讨论。这就是我们的本性。这个特性对学习编程其实还是有利的。我们坐在电脑前，独自折腾代码，不断反复，直到变得足够好，最终成功地交付项目。 但还有更好的方式。我们已经不再是学员，而在公司上班的好处，就是这里有很多熟练的开发者。开发者一起工作的时候越多，依靠这种社交方式，一个人的技能就会越快地传递给另一个开发者。如果能实施TDD这样的新流程，速度会明显快得多。结对编程是学会技术实践的好办法，一个秘密武器。不然，Vanilla Pop和初级程序员Joe依靠不断反馈的方式学习，会慢得多。 下一集，代码狗卷入了一场代码覆盖丑闻。

The post 020 TDD破坏者 first appeared on Agile Thoughts.