Agile Thoughts Podcast archive

Jose：我从其他组员那里听说了很多你在实施TDD的事情。目前来说，我是唯一的负责质量的同事，不过……你的那些测试只是针对代码的，而我又已经在测试功能了，那么这样做有什么好处呢？ Vanilla：呃，你所做的是很多的手动操作。而我们的这些测试是自动化的，而且—— Jose：而且它们是由你们开发人员来编写的？自己编写测试来检测自己所写的代码，似乎意义不大呢？那不是每项测试都能直接通过，因为你们不就是希望测试能通过吗？ Vanilla：是像这样的，就像单元测试一样—— Jose：单元测试？更像是奇幻的独角兽测试。你真地认为你们是在测试吗？它们真有什么价值吗？ Vanilla：这样的啦，单元测试很快，主要是测试开发者的意图。 Jose：我不需要什么糟糕的单元测试来告诉我开发者的意图。每个开发者都希望自己进行的测试越少越好，这样他们才有时间来编写更多的功能，并在之后进行调试修改。如果每个人都来找我抱怨，我根本顾不上他们，我进行测试的时间都会被缩短一半！ Vanilla：Jose你想想，过去4天里，我写了20个单元测试。你知道吗，它们能测试你我所写的每一行代码。 Jose：只是你写的每一行代码。真是条捷径啊！老兄，你需要清醒一点！ Vanlla：你再想想，Jose—— Jose：这甚至都不算是秘密啦，Pop！我听产品负责人说过，这些单元测试甚至都不测试功能。那它们能有什么用呢？ Vanilla：它们不直接测试功能。直接，这个词很关键！但是，它们会测试代码，实施产品功能的代码。 Jose：听听你自己在说什么，伙计。你太疯狂了。 Vanilla：不是这样的啊！ Jose：无论是否是微测试，开发人员来编写测试？这完全是两码事啊，泾渭分明的两码事! Vanilla：打住打住！你觉得开发者没有能力编写测试？ Jose：是一个很根本性的问题。因为…等等，我似乎想到了什么。 Vanilla：你到底想说什么呢？ Jose：稍等片刻。我觉得，啊，我突然明白了。它来了，没错，它来了！（做出了引用的手势） Vanilla：兄弟，这样好折腾我啊！你真是个…是个可爱的同事。我想请你看看这些微测试的名字，（传来了键盘敲击声）看见这些名字了没，他们…… Jose：（很吃惊地）这些名字就很直截了当地讲明了它们在测试什么。我终于明白了，你们的测试并不只是做做样子。棒极了！你会成为一个优秀的测试人员的。你真是个超人。我开始没弄明白你的逻辑控制链路。把整件事交给其他人，他们会觉得把测试直接交给我比较快当方便。很难得你写了这20多个测试，这并不是你们开发人员的本职工作。你能帮我一个忙吗？如果你们有微测试未通过，能让我知道一下吗？我的上司一直在关注我发现了多少个漏洞。如果这些微测试能有帮助的话，请让我知道，以便我提交它们发现的错误报告。 解说： 用开发人员编写微测试在很多公司里都会有些许争议，传统的看法认为这是质量控制的工作内容。但是，质量控制的功能是准备产品发布，质量控制经理和他的团队通常在开发完成后进行测试。因此，让他们在开发过程中测试，会让他们很困惑。实际上，在TDD里，有小部分测试甚至是在开发前完成的。由于微测试运行得如此之快，像Vanilla Pop这样的开发人员，甚至每天、每个小时，都能完成很多轮测试。这使得开发者能使用测试对所写的代码进行快速的检查，查看他们的工作是否有瑕疵，并在代码提交之前就发现错误。这样的错误检测机制，发生在传统质量控制流程、甚至宏测试之前。这个案例里，TDD实际上缩短了开发周期，使得开发者每天能写出更多的功能，同时犯更少的错误。 因为专门的测试人员会质疑开发者告诉他们的各种想法，Vanilla Pop需要赢得测试人员的支持，并且要让开发者为代码的瑕疵负责，尤其是在他们已经乐于接受编写自动化微测试之后。Jose会继续编写针对功能的自动化验收测试（宏测试），而不是着重关注能向经理提交多少错误计数；关注的重心也不应该是在设计冲刺周期中的开始阶段，编写自动化的宏测试并结合ATDD（验收测试驱动开发），据此报告有多少代码被自动化测试“覆盖”。