开发者测试：打造高质量软件的关键策略

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

《Developer Testing: Building Quality into Software》是一本由Alexander Tarlinder撰写的专业指南，专为软件开发团队提供如何在敏捷开发过程中实现无缺陷、易于维护的软件而设计。这本书强调了将开发与测试无缝融合的重要性，通过编写可测试代码，利用自动化测试来确保代码质量，避免迭代末期可能出现的“测试压力”。书中内容涵盖了多个关键知识点，包括但不限于： 1. **测试目标与风格**：探讨测试的目的，以及开发者应遵循的不同测试风格（如面向对象测试、行为驱动开发等），并明确测试人员的角色定位。 2. **测试词汇与术语**：介绍测试领域的专业术语，帮助读者理解开发者角度下的测试学科。 3. **代码可测试性**：深入解析如何从开发者视角提升代码的可测试性，包括识别影响测试性的代码结构。 4. **编程合同与契约**：解释编程合同的概念，即使在没有运行时支持的情况下，如何利用它提高代码质量。 5. **单元测试基础**：教授如何有效地命名、组织和执行单元测试，掌握经典TDD（Test-Driven Development）和“mockist-style” TDD 的核心原则。 6. **测试双面与模拟框架**：利用测试用例、桩对象或模拟框架，如Moq等，进行有效测试。 7. **处理复杂测试场景**：学会管理类、组件、层和系统间的依赖关系，应对大规模测试组合和大量相似测试的需求。 8. **代码复用与维护**：如何在无法消除代码复制的情况下，妥善管理和改进测试套件。 9. **高级测试实践**：涉及集成测试、系统测试和端到端测试，以及理解组织文化对质量保证的影响。 10. **适应敏捷团队策略**：建立适合敏捷团队的平衡且高效的测试策略。通过丰富的Java、C#、Groovy和Ruby示例，作者指导读者掌握技术中立的方法，避免陷入过深的技术细节，同时鼓励读者调整编程风格以适应测试，使测试思维成为日常工作的一部分。此外，书中还包含工具与库的推荐和源代码示例，为实际应用提供了全面的支持。这本手册是任何希望提高软件开发质量和测试效率的专业人士不可或缺的参考资源，无论是在大型还是小型团队，无论是新项目还是遗留代码的改造，都能从中获益匪浅。

ptg18145136

Foreword by Lisa Crispin

The subtitle says it all—“Building Quality into Software.” We’ve always known that

we can’t test quality in by testing after coding is “done.” Quality has to be baked in.

To do that, the entire delivery team, including developers, has to start building each

feature by thinking about how to test it. In successful teams, every team member has

an agile testing mind-set. They work with the delivery and customer teams to under-

stand what the customers need to be successful. They focus on preventing, rather

than finding, defects. They find the simplest solutions that provide the right value.

In my experience, even teams with experienced professional testers need devel-

opers who understand testing. They need to be able to talk with designers, product

experts, testers, and other team members to learn what each feature should do. They

need to design testable code. They need to know how to use tests to guide coding,

from the unit level on up. They need to know how to design test code as well as—or

even better than—production code, because that test code is our living documenta-

tion and our safety net. They need to know how to explore each feature they develop

to learn whether it delivers the right value to customers.

I’ve encountered a lot of teams where developers are paid to write production

code and pushed to meet deadlines. Their managers consider any time spent testing

to be a waste. If these organizations have testers at all, they’re considered to be less

valuable contributors, and the bugs they find are logged in a defect tracking system

and ignored. These teams build a mass of code that nobody understands and that is

difficult to change without something breaking. Over time they generally grind to a

halt under the weight of their technical debt.

I’ve been fortunate over the years to work with several developers who really

“get” testing. They eagerly engage in conversations with business experts, design-

ers, testers, analysts, data specialists, and others to create a shared understanding of

how each feature should behave. They’re comfortable pairing with testers and hap-

pily test their own work even before it’s delivered to a test environment. These are

happy teams that deliver solid, valuable features to their customers frequently. They

can change direction quickly to accommodate new business priorities.

Testing’s a vast subject, and we’re all busy, so where do you start? This book deliv-

ers key testing principles and practices to help you and your team deliver the qual-

ity your customers need, in a format that lets you pick up ideas quickly. You’ll learn

the language of testing so you can collaborate effectively with testers, customers, and

other delivery team members. Most importantly (at least to me), you’ll enjoy your

work a lot more and be proud of the product you help to build.

ptg18145136

xvii

preFaCe

I started writing this book four years ago with a very clear mental image of what I

wanted it to be and who my readers were going to be. Four years is quite a while, and

I’ve had to revise some of my ideas and assumptions, both in response to other work

in the field and because of deepening understanding of the subject. The biggest thing

that has happened during the course of those years is that the topic has become less

controversial. Several recent books adopt a stance similar to this one, and there’s some

reassuring overlap, which I interpret as being on the right track.

Why I Wrote This Book

I wrote this book because this was the book I should have read a decade ago! Ten years is

a long time, but believe it or not, I still need this book today—although for other reasons.

Roughly 10 years ago I embarked on a journey to understand software quality. I

wasn’t aware of it back then; I just knew that the code that I and my colleagues wrote

was full of bugs and made us sad and the customers unhappy. I was convinced that

having testers execute manual routines on our software wouldn’t significantly increase

its quality—and time has proven me right! So I started reading everything I could find

about software craftsmanship and testing, which led to two major observations.

First, to my surprise, these topics were often totally separated back then! Books

about writing software seldom spoke of verifying it. Maybe they mentioned one or

two testing techniques, but they tended to skip the theory part and the conceptual

frameworks needed for understanding how to work systematically with testing in dif-

ferent contexts. That was my impression at least. On the other hand, books on testing

often tended to take off in the direction of a testing process. Books on test-driven

development focused on test-driven development. This applied to blogs and other

online material too.

Second, writing testable code was harder than it initially appeared, not to men-

tion turning old legacy monoliths into something that could be tested. To get a feel-

ing for it, I had to dive deep into the areas of software craftsmanship, refactoring,

legacy code, test-driven development, and unit testing. It took a lot of deliberate

practice and study.

Based on these observations and my accumulated experience, I set some goals for

a book project:

ptg18145136

xviii Preface



Make the foundations of software testing easily accessible to developers, so

that they can make informed choices about the kind and level of verifica-

tion that would be the most appropriate for code they’re about to ship. In my

experience, many developers don’t read books or blogs on testing, yet they

keep asking themselves: When have I tested this enough? How many tests

do I need to write? What should my test verify? I wanted these to become

no-brainers.



Demonstrate how a testing mind-set and the use of testing techniques can

enrich the daily routines of software development and show how they can

become a developer’s second nature.



Create a single, good enough body of knowledge on techniques for writing test-

able code. I realized that such a work would be far from comprehensible, espe-

cially if kept concise, but I wanted to create something that was complete enough

to save the readers from plowing through thousands of pages of books and online

material. I wanted to provide a “map of the territory,” if you will.

This is why I should have had a book written with these goals in mind a decade

ago, but why today? Hasn’t the world changed? Hasn’t there been any progress in the

industry? And here comes the truly interesting part: this book is just as applicable

today as it would have been 10 years ago. One reason is that it’s relatively technol-

ogy agnostic. Admittedly it is quite committed to object-oriented programming,

although large parts hold true for procedural programming, and some contents apply

to functional programming as well. Another reason is that progress in the field it cov-

ers hasn’t been as impressive as in many others. True, today, many developers have

grasped the basics of testing, and few, if any, new popular frameworks and libraries

are created without testability in mind. Still, I’d argue that it’s orders of magnitude

easier to find a developer who’s a master in writing isomorphic JavaScript applica-

tions backed by NoSQL databases running in the cloud than to find a developer who’s

really good at unit testing, refactoring, and, above all, who can remain calm when the

going gets tough and keep applying developer testing practices in times of pressure

from managers and stressed-out peers.

Being a consultant specializing in software development, training, and men-

toring, I’ve had the privilege to work on several software development teams and to

observe other teams in action. Based on these experiences, I’d say that teams and

developers follow pretty much the same learning curve when it comes to quality

assurance. This book is written with such a learning curve in mind, and I’ve done my

best to help the reader overcome it and progress as fast as possible.

ptg18145136

Preface xix

Target Audience

This is a book for developers who want to write better code and who want to avoid

creating bugs. It’s about achieving quality in software by acknowledging testability

as a primary quality attribute and adapting the development style thereafter. Readers

of this book want to become better developers and want to understand more about

software testing, but they have neither the time nor support from their peers, not to

mention from their organizations.

This is not a book for beginners. It does explain many foundations and basic

techniques, but it assumes that the reader knows how to work his development envi-

ronment and build system and is no stranger to continuous integration and related

tooling, like static analysis or code coverage tools. To get the most out of this book,

the reader should have at least three years of experience creating software profession-

ally. Such readers will find the book’s dialogues familiar and should be able to relate

to the code samples, which are all based on real code, not ideal code.

I also expect the reader to work. Even though my ambition is to make lots of

information readily available, I leave the knowledge integration part to the reader.

This is not a cookbook.

About the Examples

This book contains a lot of source code. Still, my intention was never to write a pro-

gramming book. I want this to be a book on principles and practices, and as such, it’s

natural that the code examples be written in different languages. Although I’m trying

to stay true to the idioms and structure used in the various languages, I also don’t

want to lose the reader in fancy details specific to a single language or framework;

that is, I try to keep the examples generic enough so that they can be read by anyone

with a reasonable level of programming experience. At times, though, I’ve found this

stance problematic. Some frameworks and languages are just better suited for certain

constructs. At other times, I couldn’t decide, and I put an alternative implementation

in the appendix. The source code for the examples in the book and other related code

are available on the book’s companion website—http://developertesting.rocks.

How to Read This Book

This book has been written with a very specific reader in mind: the pressed-for-time

developer who needs practical information about a certain topic without having to

read tons of articles, blogs, or books. Therefore, the underlying idea is that each chap-

ter should take no more than one hour to read, preferably less. Ideally, the reader

should be able to finish a chapter while commuting to work. As a consequence, the

剩余341页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

开发者测试：打造高质量软件的关键策略

developer.express.net.windowsforms 1001

developer.amazon.com

https://developer.apple.com

gpg: 警告：无法获取 URI http://developer.download.nvidia.com/jetson/jetson-ota-public.asc：无数据

https://developer.nvidia.com/cuda-toolkit

/developer.downloa

https://developer.android.com/studio/legacy/#downloads

https://developer.android.com/studio/#command-tools打不开

最新资源