极客之家推荐代码整洁之道--读书笔记(7)这篇文章给大家，欢迎收藏极客之家享受知识的乐趣

代码整洁之道

简介：

本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。

本书适合所有程序员阅读，也可供所有想成为具备职业素养的职场人士参考。

第七章 验收测试

专业开发人员既要做好开发，也要做好沟通。“输入糟糕，输出也会糟糕”对程序员同样适用，所以职业程序员会重视与团队及业务部门的沟通，确保这种沟通的准确、流畅。

7.1 需求的沟通

过早精细化

做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。业务方还没有启动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种精确。

不确定性：

在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。

预估焦虑：需求是一定会变化的，所以追求那种精确性是徒劳的。

迟来的模糊性：

避免过早精细化的办法是尽可能地推迟精细化。专业开发人员直到着手开发的前一刻才会把需求具体化。但是，这可能造成另一个问题：迟来的模糊性。

需求文档中的每一点模糊之处，都对应着业务方的一点分歧。当然，模糊不只来自于分歧或争论。有时候，业务方会想当然地认为看文档的人懂得自己的意思

7.2 验收测试

在本章，我们把验收测试定义为业务方与开发方合作编写的测试，其目的在于确定需求已经完成。

”完成“的定义

完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这，才是完成。

那么，怎样能达到这种程度的完成，同时不影响迭代的速度呢？你应该编写整套的自动化测试，它们全都通过，就意味着满足了所有的要求。如果对功能的验收测试全部通过，就算真正完成了。专业开发人员会根据自动化的验收测试来定义需求。他们与业务方和QA一起工作，确保自动化测试能够真正覆盖完成所需的各项指标。

沟通：

验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方对验收测试达成共识，大家都能明白系统的行为将会是怎样。各方都应当记录这种准确的共识。在专业开发人员看来，与业务方、测试方协同工作，确保大家都明白要做的是什么，是自己的责任。

自动化：专业程序员会避免这种情况。相比手动测试，自动化测试的成本非常低，让人手工执行测试脚本不划算。专业开发人员认为，实现验收测试的自动化是自己的责任。

专业开发人员对待自动化这种额外工作的态度：

写这么多测试，看起来的确是大量额外工作。这根本不是什么额外工作。

写这些测试是为了确定系统的各项指标符合要求。确定这些细节指标的目的，是为了确定系统的指标；只有确定这些细节指标，我们这些程序员才能确知“完成”；只有确定这些细节指标，业务方才能确认他们花钱开发的系统确实满足了需求；只有确认这些指标，才可以真正做到自动化测试。

所以，不要把它们看作额外的工作，而应当看成节省时间和金钱的办法。这些测试可以避免你的开发误入歧途，也可以帮你确认自己已经完工。

验收测试什么时候写，由谁来写：

通常会把测试交给业务分析员、QA甚至是开发人员。如果只能由开发人员来写测试，应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。

通常，业务分析员测试“正确路径”，以证明功能的业务价值；QA则测试“错误路径”、边界条件、异常、例外情况，因为QA的职责是考虑哪些部分可能出问题。

遵循“推迟精细化”的原则，验收测试应该越晚越好，通常是功能执行完成的前几天。在敏捷项目中，只有在选定了下一轮迭代（Iteration）或当前冲刺（Sprint）所需要的功能之后，才编写测试。

开发人员的角色：开发人员有责任把验收测试与系统联系起来，然后让这些测试通过。

• 身为专业开发人员，与编写测试的人协商并改进测试是你的职责。绝不能被动接受测试，更不能对自己说：“噢，测试是这么要求的，我就得这么办。
• ”请记住，身为专业开发人员，你的职责是协助团队开发出最棒的软件。也就是说，每个人都需要关心错误和疏忽，并协力改正。

验收测试和单元测试区别：

首先，尽管两者测试的可能是同一个对象，其机制和路径却是不同的。单元测试是深入系统内部进行，调用特定类的方法；验收测试则是在系统外部，通常是在API或者是UI级别进行。所以两者的执行路径是截然不同的。

它们的主要功能其实不是测试，测试只是它们的附属职能。单元测试和验收测试首先是文档，然后才是测试。它们的主要目的是如实描述系统的设计、结构、行为。它们当然可以验证设计、结构、行为是否达到了具体指标，但是，它们的真正价值不在测试上，而在具体指标上。

图形界面：

• 更好的办法是，测试系统功能时，应当调用真实的API，而不是GUI。
• 几十年来，设计专家一直在教导我们，要把GUI和业务逻辑分开。

持续集成：

请务必确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码，持续集成系统就会开始构建，并运行所有的测试，测试结果会用电子邮件发送给团队所有人。

持续集成不应该失败，如果失败了，团队里的所有人都应该停下手里的活，看看如何让测试通过。在持续集成系统里，失败的集成应该视为紧急情况，也就是“立刻中止”型事件。

结论

交流细节信息是件麻烦事。尤其是开发方和业务方交流关于程序的细节时，更是如此。通常，各方握手言欢，以为其他人都明白自己的意思。双方以为取得了共识，然后带着截然不同的想法离开，这种事太平常不过了。

要解决开发方和业务方沟通问题，我所知道的唯一有效的办法就是编写自动化的验收测试。这些测试足够正式，所以其结果有权威性。这些测试不会造成模糊，也不可能与真实系统脱节。它们，就是无可挑剔的需求文档。

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！