测试驱动的iOS开发实践

需积分: 10 141 浏览量更新于2024-07-21 收藏 3.47MB PDF 举报

"Addison.Wesley.Test-Driven.iOS.Development" 是一本专注于在iOS开发中实践测试驱动开发（TDD）的专业书籍。该书通过深入浅出的方式，旨在帮助iOS开发者掌握如何有效地运用TDD原则和技巧来提高软件质量和可维护性。作者详细介绍了软件测试和单元测试的基本概念，强调了其在软件开发过程中的重要性。在“Chapter 1. About Software Testing and Unit Testing”中，读者将学习到软件测试的目的、不同类型的测试以及单元测试的核心理念。单元测试是TDD的基础，它允许开发者针对代码的最小可测试单元进行验证。 “Chapter 2. Techniques for Test-Driven Development”探讨了实施TDD的各种策略和最佳实践，如红-绿-重构循环，以及如何在开发过程中保持测试先行。这些技巧有助于开发者编写更健壮、更易于维护的代码。在“Chapter 3. How to Write a Unit Test”中，作者详细阐述了编写高效、可读性强的单元测试的方法，包括断言的使用、测试隔离以及测试覆盖率的考虑。 “Chapter 4. Tools for Testing”介绍了iOS开发中常用的测试工具和框架，如XCTest，以及如何集成它们到开发流程中。这些工具对于实现自动化测试和持续集成至关重要。从“Chapter 5”到“Chapter 10”，作者逐步展示了如何在实际的iOS应用开发中运用TDD，涵盖了数据模型、应用逻辑、网络编程、视图控制器等多个关键领域。每个章节都通过具体的例子来演示如何在这些特定场景下进行TDD。 “Chapter 11. Designing for Test-Driven Development”讨论了如何在设计阶段就考虑到TDD，以便于创建更加测试友好和模块化的架构。 “Chapter 12. Applying Test-Driven Development to an Existing Project”关注于如何在已有的项目中引入TDD，解决在维护和扩展旧代码时面临的挑战。最后，“Chapter 13. Beyond Today’s Test-Driven Development”展望了TDD的未来，讨论了当前TDD方法的局限性以及可能的发展趋势。这本书是iOS开发者提升测试技能、实现高质量开发的重要参考资料，尤其适合希望采用TDD来改进开发流程和提高产品质量的团队和个人。通过阅读此书，开发者不仅可以学习到TDD的理论知识，还能获得实战经验，从而在实际项目中更好地应用TDD。

ptg7913098

About Software Testing

and Unit Testing

To gain the most benefit from unit testing, you must understand its purpose and how it

can help improve your software. In this chapter, you learn about the “universe” of soft-

ware testing, where unit testing fits into this universe, and what its benefits and draw-

backs are.

What Is Software Testing For?

A common goal of many software projects is to make some profit for someone.The

usual way in which this goal is realized is directly, by selling the software via the app

store or licensing its use in some other way. Software destined for in-house use by the

developer’s business often makes its money indirectly by improving the efficiency of

some business process, reducing the amount of time paid staff must spend attending to

the process. If the savings in terms of process efficiency is greater than the cost of devel-

oping the software, the project is profitable. Developers of open source projects often sell

support packages or use the software themselves: In these cases the preceding argument

still applies.

So, economics 101: If the goal of a software project is to make profit—whether the

end product is to be sold to a customer or used internally—it must provide some value

to the user greater than the cost of the software in order to meet that goal and be suc-

cessful. I realize that this is not a groundbreaking statement, but it has important ramifi-

cations for software testing.

If testing (also known as Quality Assurance, or QA) is something we do to support our

software projects, it must support the goal of making a profit.That’s important because it

automatically sets some constraints on how a software product must be tested: If the test-

ing will cost so much that you lose money, it isn’t appropriate to do. But testing software

can show that the product works; that is, that the product contains the valuable features

expected by your customers. If you can’t demonstrate that value, the customers may not

buy the product.

ptg7913098

Notice that the purpose of testing is to show that the product works, not discover

bugs. It’s Quality Assurance, not Quality Insertion. Finding bugs is usually bad.Why?

Because it costs money to fix bugs, and that’s money that’s being wasted because you

were being paid to write the software without bugs in in the first place. In an ideal

world, you might think that developers just write bug-free software, do some quick test-

ing to demonstrate there are no bugs, and then we upload to iTunes Connect and wait

for the money to roll in. But hold on:Working like that might introduce the same cost

problem, in another way. How much longer would it take you to write software that you

knew, before it was tested, would be 100% free of bugs? How much would that cost?

It seems, therefore, that appropriate software testing is a compromise: balancing the level

of control needed on development with the level of checking done to provide some confi-

dence that the software works without making the project costs unmanageable. How

should you decide where to make that compromise? It should be based on reducing the

risk associated with shipping the product to an acceptable level. So the most “risky” com-

ponents—those most critical to the software’s operation or those where you think most

bugs might be hiding—should be tested first, then the next most risky, and so on until

you’re happy that the amount of risk remaining is not worth spending more time and

money addressing.The end goal should be that the customer can see that the software does

what it ought, and is therefore worth paying for.

Who Should Test Software?

In the early days of software engineering, projects were managed according to the

“waterfall model” (see Figure 1.1).

In this model, each part of the development process

was performed as a separate “phase,” with the signed-off output of one phase being the

input for the next. So the product managers or business analysts would create the prod-

uct requirements, and after that was done the requirements would be handed to design-

ers and architects to produce a software specification. Developers would be given the

specification in order to produce code, and the code would be given to testers to do

quality assurance. Finally the tested software could be released to customers (usually ini-

tially to a select few, known as beta testers).

Chapter 1 About Software Testing and Unit Testing

1. In fact, many software projects, including iOS apps, are still managed this way. This fact

shouldn’t get in the way of your believing that the waterfall model is an obsolete historical

accident.

ptg7913098

Tab le 1. 1 Cost of Fixing Bugs Found at Different Stages of the Software Development

Process

Cost of

Bugs Time Detected

Time System Post-

Introduced Requirements Architecture Coding Test Release

Requirements 1 3 5–10 10 10–100

Architecture - 1 10 15 25–100

Coding - - 1 10 10–25

Where does this additional cost come from? A significant part is due to the communica-

tion between different teams: your developers and testers may use different terminology

to describe the same concepts, or even have entirely different mental models for the

same features in your app.Whenever this occurs, you’ll need to spend some time clearing

up the ambiguities or problems this causes.

The table also demonstrates that the cost associated with fixing bugs at the end of the

project depends on how early the bug was injected:A problem with the requirements

can be patched up at the end only by rewriting a whole feature, which is a very costly

undertaking.This motivates waterfall practitioners to take a very conservative approach

to the early stages of a project, not signing off on requirements or specification until they

believe that every “i” has been dotted and every “t” crossed.This state is known as analy-

sis paralysis, and it increases the project cost.

Separating the developers and testers in this way also affects the type of testing that is

done, even though there isn’t any restriction imposed. Because testers will not have the

same level of understanding of the application’s internals and code as the developers do,

they will tend to stick to “black box” testing that treats the product as an opaque unit

that can be interacted with only externally.Third-party testers are less likely to adopt

“white box” testing approaches, in which the internal operation of the code can be

inspected and modified to help in verifying the code’s behavior.

The kind of test that is usually performed in a black box approach is a system test,or

integration test.That’s a formal term meaning that the software product has been taken as

a whole (that is, the system is integrated), and testing is performed on the result.These

tests usually follow a predefined plan, which is the place where the testers earn their

salary:They take the software specification and create a series of test cases, each of which

describes the steps necessary to set up and perform the test, and the expected result of

doing so. Such tests are often performed manually, especially where the result must be

interpreted by the tester because of reliance on external state, such as a network service

or the current date. Even where such tests can be automated, they often take a long time

to run:The entire software product and its environment must be configured to a known

baseline state before each test, and the individual steps may rely on time-consuming

interactions with a database, file system, or network service.

Chapter 1 About Software Testing and Unit Testing

ptg7913098

Beta testing, which in some teams is called customer environment testing, is really a spe-

cial version of a system test.What is special about it is that the person doing the testing

probably isn’t a professional software tester. If any differences exist between the tester’s

system configuration or environment and the customer’s, or use cases that users expect to

use and the project team didn’t consider, this will be discovered in beta testing, and any

problems associated with this difference can be reported. For small development teams,

particularly those who cannot afford to hire testers, a beta test offers the first chance to

try the software in a variety of usage patterns and environments.

Because the beta test comes just before the product should ship, dealing with beta

feedback sometimes suffers as the project team senses that the end is in sight and can

smell the pizza at the launch party. However, there’s little point in doing the testing if

you’re not willing to fix the problems that occur.

Developers can also perform their own testing. If you have ever pressed Build &

Debug in Xcode, you have done a type of white-box testing:You have inspected the

internals of your code to try to find out more about whether its behavior is correct (or

more likely, why it isn’t correct). Compiler warnings, the static analyzer, and Instruments

are all applications that help developers do testing.

The advantages and disadvantages of developer testing almost exactly oppose those of

independent testing:When developers find a problem, it’s usually easier (and cheaper) for

them to fix it because they already have some understanding of the code and where the

bug is likely to be hiding. In fact, developers can test as they go, so that bugs are found

very soon after they are written. However, if the bug is that the developer doesn’t under-

stand the specification or the problem domain, this bug will not be discovered without

external help.

Getting the Requirements Right

The most egregious bug I have written (to date, and I hope ever) in an application fell into

the category of “developer doesn’t understand requirements.” I was working on a systems

administration tool for the Mac, and because it ran outside any user account, it couldn’t

look at the user settings to decide what language to use for logging. It read the language

setting from a file. The file looked like this:

LANGUAGE=English

Fairly straightforward. The problem was that some users of non-English languages were

reporting that the tool was writing log files in English, so it was getting the choice of lan-

guage wrong. I found that the code for reading this file was very tightly coupled to other

code in the tool, so set about breaking dependencies apart and inserting unit tests to find

out how the code behaved. Eventually, I discovered the problem that was occasionally caus-

ing the language check to fail and fixed it. All of the unit tests pass, so the code works,

right? Actually, wrong: It turned out that I didn’t know the file can sometimes look at this:

LANGUAGE=en

Who Should Test Software?

剩余243页未读，继续阅读

raymondweng

粉丝: 0
资源: 9

测试驱动的iOS开发实践

Addison.Wesley.XML.- A Manager's Guide, Second Edition.chm

Addison.Wesley.PCI.Express.System.Architecture.eBook-LiB.chm

[计算机科学经典著作].Addison.Wesley.-.Meyers.-.More.Effective.C++.1st.Edition.pdf

Addison.Wesley.Test.Driven.JavaScript.Development.Sep.2010.rar

[计算机科学经典著作].Addison.Wesley.-.Exceptional.C

[计算机科学经典著作].Addison.Wesley.-.Exceptional.C++.rar

[计算机科学经典着作].Addison.Wesley.-.Exceptional.C++.pdf

[计算机科学经典著作].Addison.Wesley.-.More.Exceptional.C++.pdf

[计算机科学经典著作].Addison.Wesley.-.More.Exceptional.C..rar

Addison.Wesley.Learning.Objective-C.2.0

最新资源