Google工程师分享：提升代码可测试性的单元测试策略

PDF文件

单元测试

可测试性

google

下载需积分: 50 | 931KB | 更新于2024-07-23 | 26 浏览量 | 举报收藏

立即下载

在IT行业中，编写可测试性代码是至关重要的，尤其是在大型项目和高度依赖性的系统中。这篇指南由Google的软件工程师们分享，旨在提供一系列关于如何提升代码可测试性的实用建议，以保持代码的最佳状态。作者包括Jonathan Wolter、Russ Ruffer和Miško Hevery，他们的经验和洞察源自《编写可测试代码》(Writing Testable Code)一文。 1. **单元测试可测试性的重要性**: 单元测试是一种软件测试方法，专注于检查代码中的最小可测试单元（如函数或方法）。提高代码的可测试性意味着设计时考虑了测试的便利性和效率，使得每个功能模块都可以独立地进行验证。这有助于早期发现和修复错误，提高软件质量和维护性。 2. **识别不具有可测试性的代码问题**: 文档列举了三个主要的代码缺陷，它们分别是： - **过度依赖协作对象**：代码如果过于依赖外部组件，难以隔离单元进行测试。 - **类做太多事情**：一个类承担过多职责可能导致难以测试其中的特定功能。 - **构造器执行实际工作**：构造函数通常用于初始化对象，但若包含过多逻辑或操作，会妨碍单元测试。 3. **解决策略**: 对于每种问题，指南提供了识别问题的方法以及相应的修复建议。例如，修复过度依赖协作对象可能涉及将相关的初始化和交互动作移到适当的时间点；通过划分职责并创建专门的接口来处理“类做太多”的情况；对于构造器的重构，可以将逻辑分离到其他适当的方法或服务中。 4. **代码示例对比**: 指南还提供了具体的代码示例，展示了问题代码和经过改进后的版本，以便读者直观理解如何应用这些原则。这有助于开发人员在实践中理解和应用可测试性原则。 5. **常见疑问解答**: 最后，针对这些话题，文章还包括了一些常见的开发者疑问及其解答，帮助读者澄清疑惑，确保他们在实施可测试性策略时能够明确目标和策略。这篇指南为开发者提供了实用的工具和思考框架，以提升代码的可测试性，从而提高软件开发的效率和质量。无论你是初学者还是经验丰富的开发者，都值得一读和遵循。

Problem: Constructor takes a partially initialized object and has to set it up

Before: Hard to Test

After: Testable and Flexible Design

// SUT initializes collaborators. This prevents

// tests and users of Garden from altering them.

class Garden {

Garden(Gardener joe) {

joe.setWorkday(new TwelveHourWorkday());

joe.setBoots(

new BootsWithMassiveStaticInitBlock());

this.joe = joe;

}

// ...

}

// Let Guice create the gardener, and have a

// provider configure it.

class Garden {

Gardener joe;

@Inject

Garden(Gardener joe) {

this.joe = joe;

}

// ...

}

// In the Module configuring Guice.

@Provides

Gardener getGardenerJoe(Workday workday,

BootsWithMassiveStaticInitBlock badBoots) {

Gardener joe = new Gardener();

joe.setWorkday(workday);

// Ideally, you'll refactor the static init.

joe.setBoots(badBoots);

return joe;

}

// A test that is very slow, and forced

// to run the static init block multiple times.

class GardenTest extends TestCase {

public void testMustUseFullFledgedGardener() {

Gardener gardener = new Gardener();

Garden garden = new Garden(gardener);

new AphidPlague(garden).infect();

garden.notifyGardenerSickShrubbery();

assertTrue(gardener.isWorking());

}

// The new tests run quickly and are not

// dependent on the slow

// BootsWithMassiveStaticInitBlock

class GardenTest extends TestCase {

public void testUsesGardenerWithDummies() {

Gardener gardener = new Gardener();

gardener.setWorkday(new OneMinuteWorkday());

// Okay to pass in null, b/c not relevant

// in this test.

gardener.setBoots(null);

Garden garden = new Garden(gardener);

new AphidPlague(garden).infect();

garden.notifyGardenerSickShrubbery();

assertTrue(gardener.isWorking());

}

Object graph creation (creating and configuring the Gardener collaborator for Garden) is a different

responsibility than what the Garden should do. When configuration and instantiation is mixed together

in the constructor, objects become more brittle and tied to concrete object graph structures. This

makes code harder to modify, and (more or less) impossible to test.

 Flaw: The Garden needs a Gardener, but it should not be the responsibility of the Garden to

configure the gardener.

 Flaw: In a unit test for Garden the workday is set specifically in the constructor, thus forcing us

to have Joe work a 12 hour workday. Forced dependencies like this can cause tests to run slow.

In unit tests, you’ll want to pass in a shorter workday.

 Flaw: You can’t change the boots. You will likely want to use a test-double for boots to avoid

the problems with loading and using BootsWithMassiveStaticInitBlock. (Static initialization

blocks are often dangerous and troublesome, especially if they interact with global state.)

Have two objects when you need to have collaborators initialized. Initialize them, and then pass them

fully initialized into the constructor of the class of interest.

Problem: Violating the Law of Demeter in Constructor

Before: Hard to Test

After: Testable and Flexible Design

// Violates the Law of Demeter

// Brittle because of excessive dependencies

// Mixes object lookup with assignment

class AccountView {

User user;

AccountView() {

user = RPCClient.getInstance().getUser();

}

class AccountView {

User user;

@Inject

AccountView(User user) {

this.user = user;

}

// The User is provided by a GUICE provider

@Provides

User getUser(RPCClient rpcClient) {

return rpcClient.getUser();

}

// RPCClient is also provided, and it is no longer

// a JVM Singleton.

@Provides @Singleton

RPCClient getRPCClient() {

// we removed the JVM Singleton

// and have GUICE manage the scope

return new RPCClient();

}

// Hard to test because needs real RPCClient

class ACcountViewTest extends TestCase {

public void testUnfortunatelyWithRealRPC() {

AccountView view = new AccountView();

// Shucks! We just had to connect to a real

// RPCClient. This test is now slow.

// ...

}

// Easy to test with Dependency Injection

class AccountViewTest extends TestCase {

public void testLightweightAndFlexible() {

User user = new DummyUser();

AccountView view = new AccountView(user);

// Easy to test and fast with test-double

// user.

// ...

}

In this example we reach into the global state of an application and get a hold of the RPCClient

singleton. It turns out we don’t need the singleton, we only want the User. First: we are doing work

(against static methods, which have zero seams). Second: this violates the “Law of Demeter”.

 Flaw: We cannot easily intercept the call RPCClient.getInstance() to return a mock RPCClient for

testing. (Static methods are non-interceptable, and non-mockable).

 Flaw: Why do we have to mock out RPCClient for testing if the class under test does not need

RPCClient?(AccountView doesn’t persist the rpc instance in a field.) We only need to persist the

User.

 Flaw: Every test which needs to construct class AccountView will have to deal with the above

points. Even if we solve the issues for one test, we don’t want to solve them again in other

tests. For example AccountServlet may need AccountView. Hence in AccountServlet we will

have to successfully navigate the constructor.

In the improved code only what is directly needed is passed in: the User collaborator. For tests, all you

need to create is a (real or test-double) User object. This makes for a more flexible design and enables

better testability.

We use Guice to provide for us a User, that comes from the RPCClient. In unit tests we won’t use

Guice, but directly create the User and AccountView.

剩余37页未读，继续阅读

刘备

粉丝: 0

Google工程师分享：提升代码可测试性的单元测试策略

单元测试之道Java版-使用JUnit

NUnit单元测试--讲解PPT

软件开发计划书之十一：单元测试阶段--单元测试报告

Android测试代码分享：sherlock-master项目

基本路径测试法：单元测试用例编写指南

编写高效单元测试：基于Spring的清洁测试用例实践

Qt单元测试的代码实现与示例解析

Python自动化统计Java代码行数及单元测试实现

利用JUnit与Mock实现Java单元测试及代码覆盖率提升

浮点运算单元FPU的Verilog实现与测试代码

最新资源