Swift编程：测试驱动与行为驱动开发实战

需积分: 9 131 浏览量更新于2024-07-18 收藏 11.77MB PDF 举报

"iOS Code Testing: Test-Driven Development and Behavior-Driven Development with Swift" by Abhishek Mishra 这本书深入探讨了在iOS开发中实施测试驱动开发（TDD）和行为驱动开发（BDD）的实践与策略，特别关注Swift编程语言的使用。作者Abhishek Mishra是一位经验丰富的开发者，他通过本书向读者分享了如何在iOS项目中建立健壮的测试框架，以确保代码质量和可维护性。测试驱动开发（TDD）是一种软件开发方法论，其中编写测试用例是开发过程的第一步。在TDD中，开发者首先定义一个失败的单元测试，然后编写足够的代码来使测试通过，最后重构代码以保持简洁。这种工作流程强调了设计的早期考虑和避免缺陷的重要性。在iOS开发中，使用Swift语言进行TDD时，开发者可以利用Xcode内置的 XCTest 框架或者第三方测试库如Quick和Nimble。行为驱动开发（BDD）则更侧重于业务需求和用户行为，它鼓励编写描述系统行为的自然语言规范。这些规范转化为可执行的测试，确保软件的功能符合预期。在Swift环境中，CucumberSwift和Gherkin等工具可以帮助实现BDD，它们允许非技术人员（如产品经理或客户）理解并参与到测试规范的创建过程中。书中可能会涵盖以下知识点： 1. **Swift基础**：介绍Swift的基础语法，变量、类型推断、枚举、结构体、类、协议等，为理解后续的测试代码打下基础。 2. **XCTest框架**：讲解如何使用Xcode内置的测试框架进行单元测试和集成测试，包括断言的使用、模拟对象和依赖注入。 3. **TDD实践**：详述TDD的红-绿-重构步骤，以及如何在iOS项目中应用TDD原则，提高代码质量。 4. **第三方测试库**：介绍Quick和Nimble等第三方测试工具，如何使用它们来增强测试表达性和简洁性。 5. **BDD概念**：解释BDD的基本思想，包括Given-When-Then模式，以及如何将业务规则转化为测试。 6. **CucumberSwift和Gherkin**：教授如何使用这些工具将业务规范转换为可执行的测试脚本，促进跨团队沟通。 7. **持续集成与自动化测试**：讨论如何设置持续集成服务器（如Jenkins或CircleCI），自动运行测试并集成到开发流程中。 8. **测试覆盖率**：讲解如何度量和追踪测试覆盖率，以及其在优化测试策略中的作用。 9. **模拟和桩对象**：如何使用Mocking和Stubbing技术来隔离和测试复杂系统的组件。 10. **错误处理和异常测试**：讨论Swift的错误处理机制，并指导如何编写针对异常情况的测试。通过这本书，读者不仅可以学习到如何在Swift环境中进行有效的测试，还能理解如何将TDD和BDD理念融入日常开发实践中，从而提升软件开发的质量和效率。

xix

Acknowledgments

This book would not have been possible without the support of the team at Apress

including Aaron Black and Jessica Vakili. I would also like to thank Chaim Krause for

taking the time to read the entire manuscript and his keen eye for detail. It has been my

privilege to work with you. Thank you.

A. Mishra, iOS Code Testing, DOI 10.1007/978-1-4842-2689-6_1

CHAPTER 1

Introduction to Test-Driven

Development

Well over a billion apps have been developed for the iOS platform since its inception.

Most of the early apps were rather simple and often developed by a single developer.

Over the years, iOS apps have become increasingly complex pieces of software that

often involve large, distributed teams of developers working in Agile environments with

complex build and release pipelines.

Modern apps often perform several complex operations including (but not limited to)

presenting a complex user interface, multithreading, storing data in local databases,

interfacing with multiple sensors, media recording and playback, and consuming

RESTful web API’s.

With such a complex interplay between components of an app and several thousand

lines of source code spread across several hundred classes, how do we know for certain

that the code we have written does what we think it does? How do we know that our

code can handle edge scenarios? And finally, how do we know that we have built the

right software that meets business requirements? The answer to the first two questions

is addressed by the practice of unit testing, and Behavior-Driven Development (BDD)

addresses the answer to the question of building the right software in the first place. BDD

is covered in Chapter 10. In this chapter and the next one you will learn about unit testing,

and the related discipline of Test-Driven Development (TDD).

What Is Test-Driven Development?

Test Driven Development (TDD) has its roots in a programming paradigm called Extreme

Programming

(XP), created by Kent Beck in 1996. The use of the word “extreme” signifies

a radical departure from standard programming practices of that time.

TDD is designed to provide developers with a tangible way to prove that the code

they have written does what they think it does, and to provide some confidence that the

new code that has been written does not cause any potential side effects with existing

code.

www.ebook3000.com

CHAPTER 1 ■ INTRODUCTION TO TEST-DRIVEN DEVELOPMENT

Central to the TDD approach is the concept that a developer not only writes actual

code to carry out the app’s functionality but also tests code that ensures his application’s

code does what it is supposed to do. The test code is not shipped with the product.

While writing test code in addition to code that carries out the app’s intended

functionality is indeed extra work, it should be seen as an up-front investment toward

improving the quality of the product that ships to customers. A team that practices TDD

techniques will, over time, observe a reduction in the number of regression defects.

■ Note TDD is often used interchangeably with the term Unit Test; however, these two

terms are not the same thing. TDD is an approach to software development where the test

code is written first: in essence, the tests drive development.

A unit test is just a piece of test code viewed in isolation. A unit test is one of the by-

products of adopting a TDD approach.

However, the mere existence of one or more unit tests does not necessarily imply

that the developer followed a TDD approach. The unit tests could, for instance, have been

fitted retrospectively to existing code.

If you find working on large problems overwhelming, you may find TDD to be a

useful technique to break down a problem into smaller ones, use tests to solve the smaller

problems, and in the process end up solving the larger problem. You will soon realize that

large problems are not as overwhelming once you approach them with a TDD mindset.

TDD Terminology

This section examines some of the common terminology associated with Test-Driven

Development.

Subject under Test

This is usually a piece of code, or unit of functionality you wish to test. In most situations

the subject under test is usually a single method of a Swift class. However, you may

encounter scenarios where a small group of methods or classes are being tested together.

In such cases, the subject under test usually represents a complete functionality or user

journey. The subject under test is sometimes also known as the system under test.

Unit Test

This is the piece of code that tests the subject under test. A unit test is also known as a

“test case.” Unit tests work by calling the subject under test under controlled conditions,

and verifying some kind of expected behavior. It is common for an application to have

hundreds of unit tests with each test testing a very small piece of the functionality.

Individual unit tests are implemented as independent methods of a Swift class that

derives from an XCTestCase. This Swift class is also commonly referred to as a test class.

CHAPTER 1 ■ INTRODUCTION TO TEST-DRIVEN DEVELOPMENT

In most cases you will create one test class for each class you wish to test. The XCTestCase

class is part of the XCTest framework, and the framework must be imported with an import

statement. The following code listing contains a simple test class with one unit test:

import XCTest

@testable import LoginService

class LoginServiceTests: XCTestCase {

func testExample() {

// insert test code here.

}

■ Note The code that forms these unit tests is not part of the code base that will ship

to the clients. Unit tests are typically executed every time a developer attempts to create a

build, with the build being created only if all tests pass.

The method signature of a unit test is similar to that of a method that takes no

arguments and does not return a value. However, the name of a unit test method always

begins with the keyword “test.” There are usually strict naming conventions followed for

unit test methods; these will be discussed in the next lesson.

State Verification Test

A state verification test is a type of unit test that calls methods on an object (subject under

test) and verifies the state of the object after calling the method. Such tests do not care

about implementation detail and will continue to pass even if the internal workings of

the methods being tested are changed in the future. State verification tests usually rely on

assertions to carry out the actual verification. Assertions are covered later in this lesson.

Interaction Test

An interaction test is a type of unit test that attempts to verify a specific sequence of

interactions between objects when a method is called. Such tests are also known as

behavior verification tests. Interaction tests do not necessarily have to involve multiple

objects. You could also use an interaction test to verify the sequence of calls to methods of

the same object.

In a complex object-oriented system, a single object may need to interact with several

other objects when a method is called. When it comes to interaction tests, the subject under

www.ebook3000.com

CHAPTER 1 ■ INTRODUCTION TO TEST-DRIVEN DEVELOPMENT

test is still a single class, and not the entire group of classes. One typically instantiates the

subject under test and uses special mock or stub versions of all the other objects involved in

the scope of the interaction test. Mock and stub objects are covered later in this lesson.

■ Note Since interaction tests verify the behavior of a group of classes, they are inherently

more fragile than state verification tests. For instance, a change in the order in which

methods are called could easily break an interaction test. One way to make interaction tests

less brittle is by reducing the number of classes covered by the scope of the test.

Negative Test

A negative unit test is one that verifies something did not happen. This can be useful in

some cases. However, one must never solely rely on negative tests. This is because while

a negative test can verify that something did not happen, it is immune to any number of

things that did happen. The code base could change considerably without have a single

negative test fail. If all your unit tests were negative tests, then your tests collectively are

providing limited value.

Negative unit tests in Swift are almost always state verification tests. Although it is

possible to create negative unit tests that are interaction tests, the relevant setup required

is quite complicated and often outweighs the value of writing the negative test.

As an example of a negative unit test in action, consider the following Swift class that

could be used to represent a bank account:

enum AccountType {

case currentAccount

case savingsAccount

}

class BankAccount {

var accountName:String

var accountNumber:String

var accountType:AccountType

private var transactions:[Transaction]

init(accountName:String,

accountNumber:String,

accountType:AccountType) {

self.accountName = accountName

self.accountNumber = accountNumber

self.accountType = accountType

self.transactions = [Transaction]()

}

剩余448页未读，继续阅读

weixin_38669689

粉丝: 27
资源: 300

Swift编程：测试驱动与行为驱动开发实战

Kent Beck的Test-Driven Development实战

探索Test-Driven Development：实践与模式详解

培养TDD思路的实战指南：《Test-Driven Development》精要

Agile Java Crafting Code with Test-Driven Development

Agile Java Crafting Code with Test-Driven Development.chm

test-driven-ios-development-swift-4-3rd(高清彩版)

Agile Java Crafting Code with Test-Driven Development_part1

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

高清彩版 test-driven ios development swift 4.0

iOS Test-Driven Development by Tutorials, 2nd Edition

最新资源