陇西做网站的公司,gif在线制作,公司网站制作网络公司,海报设计制作网站本书介绍 JavaScript专业开发人员必须具备的一个技能是能够编写可测试的代码。不管是创建新应用程序#xff0c;还是重写遗留代码#xff0c;本书都将向你展示如何为客户端和服务器编写和维护可测试的JavaScript代码。从减少代码复杂性的方法#xff0c;到单元测试、代码覆盖…本书介绍 JavaScript专业开发人员必须具备的一个技能是能够编写可测试的代码。不管是创建新应用程序还是重写遗留代码本书都将向你展示如何为客户端和服务器编写和维护可测试的JavaScript代码。从减少代码复杂性的方法到单元测试、代码覆盖率、调试、以及自动化您将全面学到如何编写让你和你同事能够轻松修复和维护的JavaScript代码。测试JavaScript代码是一个复杂的过程。本书将在很大程度上帮你简化该过程。 目标读者 本书主要目标受众是那些想成为JavaScript专业开发人员的人。初中级水平、或者专家级别的开发人员都适合阅读本书。因为每个人都可以从本书获取有用的知识。JavaScript可能不是我们所使用的唯一语言但在编写或测试程序时要用到大量JavaScript。如果有人付费让你编写JavaScript代码如果你每天都用JavaScript编写不同大小项目的话本书正是你的不二选择。如果你加入了一个必须要测试JavaScript的QA或工具团队本书也适合您阅读——第3章到第7章非常值得一读。本书的目的是使测试尽可能容易进而全部自动化。希望这本书能使大家的工作更轻松。这就是我要达到的目的。如果你编写JavaScript不太多这本书仍会为你提供很多有用的信息——特别是复杂度第2章、基于事件的架构第3章、以及调试第7章的这些章节。注意其余章节也有很多有用的信息但它们可能不会直接解决你的问题。我遇到的众多难题促使我撰写了这本书——我从之前的错误和努力工作中学到了很多所以你也应该这样从头开始养成好习惯将会让你更富有成效和快乐。 非目标读者 遗憾的是本书并不是适合所有的人。如果你有兴趣学习JavaScript建议先从其它地方学习一些该语言的基本知识然后再回到本书。如果你已经能够编写整洁、零bug的代码且这些代码有充分的文档和注释能够自动化构建、且连续运行所有单元测试和集成测试、能够生成完整的代码覆盖率code coverage报告、自动部署到生成环境这样的话本书对你可能就没多大用途了。如果不得不进行代码调试的话可以快速看一下第7章或者可以看一下第6章了解一些小技巧。如果你不经常用JavaScript现在就可以合上本书了。 内容简介 本书将在几个步骤内解决如何编写可测试的代码。首先我们将研究复杂度complexity。接着看架构选择其会限制复杂度和耦合度coupling。以此作为基础在功能层面和应用程序层面上继续测试方面的内容。我们将全面了解代码覆盖率和调试debugging然后完成自动化相关的所有内容。在本书最后大家将更全面理解“什么是”以及“如何进行”可测试的JavaScript。 第1章可测试的JavaScript 本书的最重要主题是编写和维护“可测试”的代码。但可测试的代码是什么为什么要努力编写它如何进行编写我们将从研究这些问题开始并且了解一些流行的开发理论以及它们和可测试代码之间有何联系。最后不管是是否跟着进行实战编写可测试代码的关键都在于让代码保持短小、整洁、简单、松耦合。 第2章复杂度 复杂度是很多问题的根源不仅仅是可测试性。这些问题包括可理解性和可维护性这两个因素是代码质量的关键指标。一些系统和应用程序本质上是复杂的事实上大多数应用程序都是很复杂的但在处理和表达这些复杂性时有正确的方式也有错误的方式。很显然将复杂的部分分解成一个个更小、更简单的小块是首要步骤。降低耦合度和扇出fan-out是管理复杂度的另外两种方式。在探索可测试的JavaScript时我们会研究所有这些方法甚至更多内容。 第3章基于事件的架构 讨论复杂度之后我们将深入研究基于事件的架构。该应用程序架构可以极大地降低复杂度和耦合度同时提供简单的方式将应用程序分解成更小、更自足的片段。不管应用程序是用于服务器端还是客户端或者很可能用于两者基于事件的架构均可以解决第2章中列举的很多问题。即便该架构不适合作为所有应用程序的总体架构在整体架构中肯定也会有用到基于事件架构的概念和实践的地方。 第4章单元测试 关于单元测试有很多争论。测试到底有多重要单元测试并不能发现所有的错误。像其他工具一样单元测试是可测试性的其中一部分。描述代码为“可测试”的并不意味着这些代码的测试用例是可用的而是说为这些代码编写测试用例比较简单而已。单元测试是特殊的测试因为通常它们是测试开发人员唯一要编写的。它们具有侵入性要求测试代码和程序代码隔离并且可以独立于应用程序运行。这可能会使单元测试变得有难度因为在隔离环境下独立运行测试代码是非常困难的。本书很大一部分章节都是讲解如何确保代码能够隔离运行从而使编写单元测试变得更简单。单元测试无法发现所有的Bug甚至大多数bug但它们所找到的Bug验证了运行单元测试确实是值得的。同样重要的是测试代码要遵循和即将测试的应用程序代码一样的高标准和高原则。 第5章代码覆盖率 代码覆盖率通常与单元测试有关。代码覆盖率是单元测试的一个很好的衡量标准然而我们会发现这并非总是如此。代码覆盖率不仅仅适用于单元测试所有类型的测试包括集成测试、手工测试、性能测试都可以受益于代码覆盖率。我们将研究代码覆盖率的优势和劣势以及如何生成、查看代码覆盖率、并使其变得有意义。 第6章集成测试、性能测试、负载测试 当然除了单元测试以外还有很多其他类型的测试。集成测试、手工测试、性能测试、功能测试以及其他类型的测试在寻找和挖掘Bug的工作中都发挥着很重要的作用。不管谁做这些测试工作——开发人员、QA团队甚或是不知情的用户不管你喜欢不喜欢都要完成这些类型的测试。将应用程序作为一个整体进行轻松测试的能力也是至关重要的。模块化功能使测试代码能够与实现的功能更密切相关这有助于开发人员更快地修复bug。在这些测试中使用代码覆盖可以快速显示黑盒测试期间执行的代码。大量的基于JavaScript的工具可以让开发人员用于集成测试和性能测试我们将深入研究其中一些工具给大家一个直观的展现。 第7章调试 我们编写的代码第一次编写时不管看起来多完美都是不完美的。我们的代码肯定会产生Bug可能有很多的Bug。我们想到的和意想不到的Bug都有可能会破坏代码。我们的测试、其他人的测试、或者用户使用程序时都有可能发现Bug。测试时发现的Bug是最容易解决的这也是最大化测试的一个很好的理由。用户运行程序时发现的Bug更难以追踪其结果是不仅要调试自己的代码还得调试别人的代码。针对Node.js和浏览器代码这两方面我将分享一些调试的技巧和窍门。要准备一个好用的调试环境因为我们要经常用到它。 第8章自动化 最后对于测试一遍遍地手工操作不仅不可持续而且非常无趣。软件编程是世界上手工处理过程最多的工作之一但测试和软件维护却不一定。运行测试、生成代码覆盖率报告、执行静态分析、精简和压缩代码、以及向生产环境或其他环境上部署或回滚代码都应该是自动化过程的一部分。自动化可以确保不管发生什么情况无论是成功还是失败它会很快地进行处理更重要的是在某种程度上可以重复操作。程序代码错了自动化测试就会失败、生产环境运行也会失败、其他事情也会出错但这些绝对不会关联到我们的程序代码。这就是现实。关键是要从这些失败连同你造成的故障中尽快且不着痕迹地恢复回来。 小结 编写可测试的代码会让我们的工作以及我们手下那些人的工作变得非常简单。从更少的Bug到更多容易修复的Bug、从容易测试到简单调试编写可测试的JavaScript是明智之选。本书将展示通往睿智道路的途径。阅读整本书之后大家将对编写和维护可测试的JavaScript实际需要方面有一个很好的了解。但这仅仅是一个开始。我们作为开发人员必须将这些实践和模式应用到日常工作中。必须抵制住“懒惰”且不编写测试的诱惑避免走回头路防止自己或别人来收拾我们的烂摊子。可测试的JavaScript代码将会延续。如果你现在正在编写遗留代码帮你自己和老板一个忙开始编写可测试的代码。希望你会发现这样做并不是很难而且非常有益、甚至非常有趣转载于:https://www.cnblogs.com/TomXu/p/4266774.html
