解说：Vanilla Pop向产品负责人讲述团队在做的TDD。
Horst：Vanilla Pop，你好！你的工作真做得挺好，公司里新的明星员工。你对现在的工作怎么考虑的呢？
VPop：设计冲刺（sprint）计划会议在明天。我主要在为我们团队试验性地实施TDD，而且——
Horst：TDD，是和测试有关是吗？
VPop：没错。微测试。我觉得已经可以向整个团队教授如何实施了。才开始的时候会对开发的速度有些影响，但适应了之后速度就会回升。
（脑海里的声音：会减缓一些速度？他确定这样能行吗？）
Horst：不好意思啊，Jose不是已经在测试这个App了吗？有人在测试，为什么还要另外再测试呢？
VPop：呀，这两种测试是不一样的。Jose所做的是宏测试，有些还是手动的。我们所做的是自动化微测试，只检测代码是否运作正常，而不是产品的功能。
（脑海里的声音：测试代码，而不是功能？到底是什么意思哦？）
Horst：抱歉，但Jose进行的测试，不也是在测试代码吗？不是吗？
VPop：没错，但这些测试会更详尽地测试一小段代码，代码有没有瑕疵会马上显现出来。
Horst：所以，你的意思是Jose的测试速度很慢？
VPop：其实不是。如果说他的测试速度慢的话，主要是慢在我们寻找有问题的代码这一环节。宏测试并不能帮助我们定位代码的问题在哪里。它只能让我们知道代码有问题。
Horst：但是如果你们花费时间，去编写对代码的测试，而我们已经另外有独立测试的时候，听起来有些过度测试的感觉。我更希望你们编写功能性的代码，而让Jose去处理质量控制。
VPop：并不是这样的。如果所有的开发人员都这样做的话，我们可以确保代码零瑕疵。
（脑海里的声音：“零”，他当真说的是零瑕疵吗？他真是疯了！）
Horst：如果所有的开发人员都这样做，他们就是在进行重复的多余的测试，而没有把精力花在编写软件的功能上。不行！我们必须保持更快的速度，我们一定要在市场上占据到需要的位置。产品的功能才是重点！（Horst的口号）
Every business wants features that keep working and don’t want to pay for bug fixes or have the team slow down because the code can’t be refactored. End of story.
解说：向非开发人员和质量控制人员解释微测试和宏测试的差别非常困难。这里，Vanilla Pop就像是在向非开发人员推广讲解如何进行高效开发一样。这肯定困难重重，因为他把产品负责人放到了不利的位置。不要把TDD当成是一个独立于开发的环节介绍给产品负责人。或许你会觉得这样太过于含糊了，但其实并不是。TDD对你或者你的团队是新事物，并不代表它是可省略的多余的环节。如同你应该采用良好的代码设计模式，或是给代码加上注释一样，这是你应当已经采用的一项开发实践。既然TDD是开发实践，那么，产品负责人对此作出的决定是不专业的，就像他们不应该决定代码中的错误处置和错误代码传递一样。不要把产品负责人放在这样的位置上。相反，Vanilla Pop应该继续实施TDD，花费精力让必须要使用TDD的同事，也就是其他从事开发的同事，来接纳TDD。最后，他可以简单地告知项目负责人近来工作上的改观，他们采用了一种新方法，能明显减少代码错误，同时也保持了已有的工作效率，并且能在一两个月里，提高开发新功能的速度。每一个公司都希望自己产品的功能是有效可用的。他们也希望，不要为代码上的错误而买单，或者因为无法重构代码而影响了整体工作的速度。本集故事到此结束。
下一集，我们将听到团队测试人员的想法。（Jose的口号）
用户评论