iOS开发实战：以测试为导向

5星 · 超过95%的资源需积分: 9 154 浏览量更新于2024-07-26 2 收藏 4.29MB PDF 举报

《测试驱动的iOS开发》是一本专注于介绍如何在iOS应用开发过程中采用测试驱动开发(TDD)方法的专业书籍。这本书是基于业界认可的资源，旨在帮助iOS开发者提升他们的编程技能和实践，通过系统地应用测试策略确保代码质量与可靠性。 TDD是一种软件开发方法论，它强调在编写任何实际代码之前先编写测试。这种方法的核心思想是通过设计并实现针对预期功能的测试用例，然后编写代码来满足这些测试需求，以此来驱动开发过程。在iOS开发中，这包括了对应用程序功能、性能和用户界面的各个层面进行自动化测试，确保代码的正确性并在不断迭代中持续优化。本书可能会探讨以下关键点： 1. **测试框架理解**：iOS平台提供了诸如XCTest这样的内置测试框架，开发者需要熟悉如何设置和运行单元测试、集成测试和UI测试。 2. **编写可测试的设计**：遵循SOLID原则和设计模式，使代码结构清晰，易于测试。 3. **断言和测试驱动的重构**：学习如何使用断言来验证代码行为，并利用测试作为重构的驱动力，保持代码健壮性。 4. **持续集成与持续部署(CI/CD)**：如何将测试集成到CI/CD流程中，确保每次代码提交都能自动执行测试，快速发现和修复问题。 5. **测试覆盖率和性能测试**：了解如何衡量代码覆盖率，以及如何进行压力测试和性能优化。 6. **适应新技术**：书中可能会提及如Swift和Xcode的最新特性，它们如何支持和扩展TDD实践。 7. **案例研究与实战演练**：书中可能包含一些实际项目中的TDD实施案例，帮助读者理解和应用这些概念到实际工作场景。《测试驱动的iOS开发》作为Developer's Library系列的一部分，提供高质量的教程和参考资料，适合经验丰富的iOS开发者寻求更高效的开发策略，也适合初学者学习如何在iOS开发中引入和掌握TDD的最佳实践。无论你是想改进现有项目的测试实践，还是希望开始采用TDD的新手，这本书都是值得信赖的实用指南。你可以在线或在实体书店找到这本书，如www.it-ebooks.info和informit.com/devlibrary，获取更多关于iOS开发和测试驱动开发的专业知识。

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.

www.it-ebooks.info

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.

www.it-ebooks.info

ptg7913098

Tabl e 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

www.it-ebooks.info

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?

www.it-ebooks.info

剩余243页未读，继续阅读

logcabin

粉丝: 38
资源: 6

iOS开发实战：以测试为导向

基于测试驱动的iOS开发

Swift 4.0 测试驱动 iOS 开发实战第三版

测试驱动的iOS开发实践

使用Swift进行测试驱动的iOS开发

Swift 4 TDD 教程：测试驱动的iOS开发

iOS开发中测试驱动开发的应用与实践

Swift开发：iOS媒体应用的测试驱动开发指南

Swift测试驱动开发：构建高效iOS应用

iOS开发实践：以测试驱动编程提升代码质量

iOS测试驱动开发（TDD）指南

最新资源