编写可测试的JavaScript代码

需积分: 9 65 浏览量更新于2024-07-20 收藏 8.42MB PDF 举报

"Testable JavaScript" 是一本面向专业开发人员的书籍，主要讲解如何编写和维护测试代码，适用于客户端和服务器端应用。书中涵盖了敏捷开发、测试驱动开发（TDD）、行为驱动开发（BDD）等核心概念，并介绍了如何通过模式和标准减少代码复杂性。此外，还探讨了基于事件的架构的优势，如模块化、松散耦合和可重用性，并详细讲解了单元测试、代码覆盖率、集成测试、性能测试以及负载测试的工具和方法。书中的内容还包括使用浏览器、Node.js、移动设备调试工具以及自动化开发流程。在"Testable JavaScript"中，作者Mark Ethan Trostler深入讨论了： 1. **敏捷开发**：敏捷开发是一种快速响应变化的软件开发方法，强调迭代和增量开发，鼓励团队协作和灵活应对需求变更。 2. **测试驱动开发(TDD)**：TDD是一种编程实践，要求开发者先编写测试用例，然后编写最小化的代码以使测试通过，以此确保代码的质量和功能。 3. **行为驱动开发(BDD)**：BDD强调从用户或业务角度出发定义系统行为，通过编写故事和场景来指导开发，促进团队间沟通和理解。 4. **代码复杂性的降低**：书中借鉴了静态语言中的模式和标准，如模块化设计，以减少代码的复杂性和维护难度。 5. **基于事件的架构**：这种架构模式强调事件驱动的编程，有助于创建更可扩展和解耦的系统，提升代码的可复用性。 6. **单元测试**：书中介绍了如何编写和运行单元测试，以确保代码的各个部分都能独立工作，以及如何选择合适的工具，如Jasmine或Mocha。 7. **代码覆盖率**：通过分析测试对代码的覆盖程度，评估测试的有效性，常见的工具有 Istanbul 或 Jest。 8. **集成、性能和负载测试**：这些测试用于检查系统在不同条件下的表现，书中可能提到了Selenium和CasperJS等工具。 9. **调试工具**：在浏览器（如Chrome DevTools）、Node.js和移动设备上的调试技巧，帮助定位和解决问题。 10. **自动化开发过程**：自动化构建、测试和部署过程，使用工具如Jenkins或GitLab CI/CD，提高效率并减少人为错误。 "Testable JavaScript"是一本旨在提升开发者测试技能的指南，无论你是新手还是有经验的开发人员，都能从中学到如何编写易于测试、维护和修复的高质量JavaScript代码。通过本书，你可以学会一套完整的测试策略，以适应不断变化的项目需求和技术环境。

level and at the application level. We will gain a thorough understanding of code cov‐

erag

e and debugging, and then finish it all off with a healthy dose of automation. By the

end of the book, you will have a fuller grasp of the “what” and the “how” of testable

JavaScript.

Chapter 1, Testable JavaScript

The overrriding theme of this book is writing and maintaining “testable” code. But

what is testable code? Why should we strive to write it? And how do we do so? We

will begin by exploring all of these questions, and taking a look at some popular

development methodologies and how they relate to testable code. Ultimately, what‐

ever practice you may choose to follow, the key to writing testable code lies in

keeping it small, clear, uncomplicated, and loosely coupled.”

Chapter 2, Complexity

Complexity is the root of many problems, not just testability. These problems in‐

clude understandability and maintainability, both of which are key metrics for

quality code. Some systems and applications are inherently complex; in fact, most

applications are complex, but there are right ways and wrong ways to handle and

express that complexity. Obviously, breaking down the more complex pieces into

smaller, simpler chunks is a big first step. Reducing coupling and fan-out are other

ways to manage complexity. We will investigate all of these methods, and more, in

our quest for testable JavaScript.

Chapter 3, Event-Based Architectures

After our discussion on complexity, we will dive deeper into event-based architec‐

ture. This application-level architecture can greatly reduce complexity and coupling

while providing easy ways to break down your application into smaller, more self-

sufficient pieces. Regardless of whether your application is server-side, client-side,

or (most likely) both, an event-based architecture solves many of the problems

enumerated in Chapter 2. Even if it is not suitable as the overall architecture for

every application, there certainly is a place within the overall structure to leverage

event-based architecture concepts and practices.

Chapter 4, Unit Tests

There is a lot of controversy about unit testing. How important is it? Unit tests do

not find every bug. Like all other tools, unit tests are a piece of the testability puzzle.

Describing code as “testable” does not imply that tests are available for that code;

rather, it implies that writing tests for that code would be straightforward. Unit tests

are special in that they typically are the only kind of test developers write. They are

also invasive, requiring that you isolate the code under test and execute it separately

from the application. This makes unit testing potentially difficult, as being able to

run code at the level of a single method, in isolation, can be very difficult. A large

part of Testable JavaScript ensures that your code can be executed in isolation,

xiv | Preface

thereby making unit tests much simpler to write. While unit tests do not find every

ug (or even most bugs), the ones they do find are worth the effort involved in

running them. It is also important that your test code adheres to the same high

standards and principles as the code you are testing.

Chapter 5, Code Coverage

Code Coverage typically goes hand in hand with unit testing. Code coverage can

be a good measure of unit-test efficacy; however, we will see that this is not always

the case. Yet code coverage is not just for unit testing anymore! All kinds of testing

can benefit from code coverage measurements, including integration, manual, and

performance testing. We will investigate the good and the bad of code coverage

metrics and how to generate, view, and make sense of them.

Chapter 6, Integration, Performance, and Load Testing

Of course, there is much more to testing than just unit testing. Integration, manual,

performance, functional, and other types of testing all play an important role in

finding and ferreting out bugs. Regardless of who does the testing—the developers,

the QA team, or even your unwitting users—these other kinds of tests will get done

whether you like it or not. The ability to easily test the application as a whole is also

vitally important. Modularizing functionality allows the test code to be more clearly

linked to the implemented functionality, which helps developers fix bugs faster.

Using code coverage during these tests can quickly show executed code during

black-box testing. Plenty of great JavaScript-based tools are available for developers

to leverage for integration and performance testing, and we will take a closer look

at some of those tools to give you an idea of what can be accomplished.

Chapter 7, Debugging

The code we write is not perfect, no matter how perfect it seems when we first write

it. Our code will have bugs. Lots of bugs. Stuff you thought about and stuff you did

not even conceive of will bedevil your code. Your tests, someone else’s tests, or a

user using your application will find the bugs. Bugs found by tests are by far the

easiest to fix, which is another great reason to maximize your tests. Bugs found by

users running production code are far more difficult to track down. The upshot is

that you will have to debug not only your code but also someone else’s. I’ll share

some tips and tricks for debugging both Node.js and browser code. Get a good

debugging environment set up, because you will be doing a lot of it.

Chapter 8, Automation

Finally, doing things manually over and over again is not only not sustainable but

also not very fun. Writing software is one of the most manual processes in the world,

but testing and maintaining software does not have to be. Running tests, generating

code coverage reports, performing static analysis, minifying and compressing code,

and deploying and rolling back code to and from production and other environ‐

ments should all be part of an automated process. Automation ensures that whatever

Preface | xv

happens, success or failure, it will happen quickly and, more importantly, in a way

hat can be repeated. You will fail. Tests will fail, a production launch will fail, and

things will go wrong that will have absolutely nothing to do with your code. That

is life. It is critical that you can recover from those failures (along with the failures

you have caused) as quickly and seamlessly as possible.

If You Like (or Don’t Like) This Book

If you like—or don’t like—this book, by all means, please let people know. Amazon

reviews are one popular way to share your happiness (or lack of happiness), or you can

leave reviews at the book’s website.

That website also provides a link to errata, giving you a way to let us know about typos,

errors, and other problems with the book. These errata will be visible on the page im‐

mediately, and we’ll confirm them after checking them out. O’Reilly can also fix errata

in future printings of the book and on Safari, making for a better reader experience

pretty quickly.

Recap

Writing testable code will make your life, and the lives of all who follow you, much,

much easier. From fewer bugs to more easily fixed ones, from easier testing to simpler

debugging, testable JavaScript is your gateway to sanity.

This book attempts to show you the path toward that sanity. After reading the entire

book you will have a very good understanding of what writing and maintaining testable

JavaScript actually entails. But that is only the beginning. You must fit these practices

and patterns into your daily life as a developer. You must resist the temptation to be

“lazy” and not write tests, when you are instead just kicking the can down the road for

either yourself or someone else to clean up your mess. Testable JavaScript is code that

will last. If you are currently writing legacy code, do yourself and your employer a favor

and start writing current code. I hope you will find that not only is that effort not difficult,

but it can also be extremely rewarding, and maybe even fun!

How to Contact Us

We have tested and verified the information in this book to the best of our ability, but

you may find that features have changed (or even that we have made a few mistakes!).

Please let us know about any errors you find, as well as your suggestions for future

editions, by writing to:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

xvi | Preface

Using Code Examples

Thi

s book is here to help you get your job done. In general, if this book includes code

examples, you may use the code in your programs and documentation. You do not need

to contact us for permission unless you’re reproducing a significant portion of the code.

For example, writing a program that uses several chunks of code from this book does

not require permission. Selling or distributing a CD-ROM of examples from O’Reilly

books does require permission. Answering a question by citing this book and quoting

example code does not require permission. Incorporating a significant amount of ex‐

ample code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title,

author, publisher, and ISBN. For example: “Testable JavaScript by Mark Ethan Trostler

If you feel your use of code examples falls outside fair use or the permission given above,

feel free to contact us at permissions@oreilly.com.

Safari® Books Online

Safari Books Online (w

ww.safaribooksonline.com) is an on-demand

digital library that delivers expert content in both book and video

form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and creative

professionals use Safari Books Online as their primary resource for research, problem

solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organi‐

zations, government agencies, and individuals. Subscribers have access to thousands of

books, training videos, and prepublication manuscripts in one fully searchable database

from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐

fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John

Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT

Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐

ogy, and dozens more. For more information about Safari Books Online, please visit us

online.

Thanks!

A Big Thank You to everyone who helped me cobble together this book, starting with

my former employer, Yahoo!, which green-lighted the time I needed to spend writing

during “business hours”; thanks Julia and Randy! Also a Big Shout-Out to the amazing

xviii | Preface

剩余272页未读，继续阅读

ryan-焱

粉丝: 3
资源: 27

编写可测试的JavaScript代码

unofficial-Errata-of-Testable-Javascript-Chinese:《编写可测试的Javascript代码》中文版 勘误（非官方）

digital system test and testable design pdf

postgresql insert

如何对28条测试响应集按照可测故障数的多少按照由大到小进行排序

spring bean

ASP.NET MVC

flax model

DFT工程师学习资料

QYR2024-2030全球及中国机载光电吊舱行业研究及十五五规划分析报告 wugege.pdf

KLite 是嵌入式操作系统内核，并以MIT协议开放源代码

最新资源

unofficial-Errata-of-Testable-Javascript-Chinese:《编写可测试的Javascript代码》中文版勘误（非官方）