探索Test-Driven iOS开发：单元测试的艺术

需积分: 0 201 浏览量更新于2024-07-19 收藏 3.47MB PDF 举报

"Test-Driven iOS Development - 探索单元测试在软件开发中的重要性和实践" 在iOS开发中，测试驱动开发（TDD）是一种强大的工具，可以帮助提高代码质量，减少错误，并确保软件的稳定性。本资源围绕“Test-Driven iOS Development”展开，深入探讨了单元测试在软件测试宇宙中的位置及其优点和局限性。单元测试是TDD的核心，它旨在验证应用程序中的最小可测试单元——通常是函数或方法——是否按预期工作。通过编写测试用例并在开发过程中频繁运行这些测试，开发者可以及时发现并修复问题，从而避免在后期集成阶段出现大量难以定位的错误。这种先写测试、后写实现的模式鼓励编写简洁、可读性强且易于维护的代码。在iOS开发中，利用Xcode内置的 XCTest 框架，开发者可以方便地创建和执行单元测试。每个测试用例都是独立的，这样可以确保某一部分代码的更改不会意外地影响到其他部分。同时，持续集成和持续测试的实践使得团队能够在整个开发周期内保持高质量的标准。 TDD 的主要好处包括： 1. 防止回归：当添加新功能或修改现有代码时，已存在的测试用例可以捕获任何可能导致原有功能失效的改变。 2. 提高代码质量：由于必须先编写测试，开发者会更倾向于设计易于测试的代码结构，这通常意味着更好的模块化和低耦合。 3. 文档作用：测试用例可以作为代码行为的文档，表明了函数或方法预期的工作方式。 4. 更快的调试：由于测试定位了问题的具体位置，调试过程可以更快地找到问题所在。然而，TDD 也有其局限性： 1. 初始投入成本：设置和编写测试用例需要额外的时间，特别是在项目开始阶段。 2. 不是所有问题都能被测试捕获：边界条件、性能问题和用户界面交互等可能需要其他类型的测试。 3. 测试维护：随着代码的修改，测试也需要相应更新，这增加了维护负担。了解了这些基础知识后，开发者可以决定何时以及如何在iOS项目中实施TDD策略。同时，参考《Test-Driven iOS Development》这样的资源，开发者可以进一步学习如何有效地进行单元测试，以及如何结合敏捷开发和持续集成实践来优化整个开发流程。此外，该资源提到了Developer’s Library系列，这是一个针对专业程序员提供高质量教程和参考资料的系列。例如，《PHP & MySQL Web Development》、《MySQL》、《Linux Kernel Development》、《Python Essential Reference》、《Programming in Objective-C》和《PostgreSQL》等书籍，都是各自领域的经典之作，它们可以帮助开发者深入理解并提升各种编程语言和技术的技能。这些书籍可在零售店、在线书店以及Safari Books Online订阅服务中获取。

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页未读，继续阅读

bladewangqi

粉丝: 1
资源: 1

探索Test-Driven iOS开发：单元测试的艺术

iOS Test Driven Development.zip

Test-Driven iOS Development with Swift 4(3rd) 无水印原版pdf

Test-Driven Development with Python(2nd) 无水印pdf

Test-Driven iOS Development with Swift

Test-Driven iOS Development with Swift.pdf

高清彩版 test-driven ios development swift 4.0

test-driven ios development swift 4.0.pdf

高清彩版 test-driven ios development swift 4.0 彩版

Test-Driven iOS Development with Swift 4(3rd) epub

高清彩版 test-driven ios development swift 4.0Rx.NET in Action With examples in C#

最新资源