如何编写可测试的代码 哈利勒的方法论

Understanding how to write testable code is one of the biggest frustrations I had when I finished school and started working at my first real-world job.

当我完成学业并开始从事第一份现实世界的工作时，了解如何编写可测试的代码是我最大的挫败之一。

Today, while I was working on a chapter in solidbook.io, I was breaking down some code and picking apart everything wrong with it. And I realized that several principles govern how I write code to be testable.

今天，当我在solidbook.io上写一章时，我正在分解一些代码并找出所有错误。 我意识到，有几条原则支配着我如何编写可测试的代码。

In this article, I want to present you with a straightforward methodology you can apply to both front-end and back-end code for how to write testable code.

在本文中，我想向您介绍一种简单的方法，您可以将其应用于前端代码和后端代码，以了解如何编写可测试的代码。

前提读物 (Prerequisite readings)

You may want to read the following pieces beforehand. 😇

您可能需要事先阅读以下内容。 😇

• Dependency Injection & Inversion Explained | Node.js w/ TypeScript

  依赖注入和反转解释 带TypeScript的Node.js

• The Dependency Rule

  依赖规则

• The Stable Dependency Principle - SDP

  稳定依赖原则-SDP

依赖关系 (Dependencies are relationships)

You may already know this, but the first thing to understand is that when we import or even mention the name of another class, function, or variable from one class (let's call this the source class), whatever was mentioned becomes a dependency to the source class.

您可能已经知道这一点，但是首先要了解的是，当我们从一个类中导入甚至提到另一个类，函数或变量的名称(我们称其为source类 )时，所提及的内容都将成为源类 。

In the dependency inversion & injection article, we looked at an example of a UserController that needed access to a UserRepo to get all users.

在依赖关系反转和注入文章中 ，我们看了一个UserController的示例，该示例需要访问UserRepo才能获取所有用户 。

// controllers/userController.tsimport { UserRepo } from '../repos' // Bad/*** @class UserController* @desc Responsible for handling API requests for the* /user route.**/class UserController {private userRepo: UserRepo;constructor () {this.userRepo = new UserRepo(); // Also bad.}async handleGetUsers (req, res): Promise<void> {const users = await this.userRepo.getUsers();return res.status(200).json({ users });}
}

The problem with this approach was that when we do this, we create a hard source-code dependency.

这种方法的问题在于，当我们这样做时，我们会创建一个硬的源代码依赖项 。

The relationship looks like the following:

关系如下所示：

UserController relies directly on UserRepo.

UserController直接依赖UserRepo。

This means that if we ever wanted to test UserController, we'd need to bring UserRepo along for the ride as well. The thing about UserRepo, though, is that it also brings a whole damn database connection with it as well. And that's no good.

这意味着，如果我们想测试UserController ，我们也需要带UserRepo 。 但是，关于UserRepo的事情是，它还带来了一个完整的数据库连接。 那不好。

If we need to spin up a database to run unit tests, that makes all our unit tests slow.

如果我们需要启动数据库来运行单元测试，那将使我们所有的单元测试变慢。

Ultimately, we can fix this by using dependency inversion, putting an abstraction between the two dependencies.

最终，我们可以通过使用依赖反转来解决此问题，将抽象放在两个依赖之间。

Abstractions that can invert the flow of dependencies are either interfaces or abstract classes.

可反转的依赖关系的流动抽象要么接口或抽象类 。

Using an interface to implement Dependency Inversion.

使用接口来实现依赖倒置。

This works by placing an abstraction (interface or abstract class) in between the dependency you want to import and the source class. The source class imports the abstraction, and remains testable because we can pass in anything that has adhered to the contract of the abstraction, even if it's a mock object.

通过在要导入的依赖项和源类之间放置一个抽象(接口或抽象类)来进行工作。 源类将导入抽象，并保持可测试性，因为我们可以传入遵守抽象协定的任何内容 ，即使它是模拟对象也是如此 。

// controllers/userController.tsimport { IUserRepo } from '../repos' // Good! Refering to the abstraction./*** @class UserController* @desc Responsible for handling API requests for the* /user route.**/class UserController {private userRepo: IUserRepo; // abstraction hereconstructor (userRepo: IUserRepo) { // and herethis.userRepo = userRepo;}async handleGetUsers (req, res): Promise<void> {const users = await this.userRepo.getUsers();return res.status(200).json({ users });}
}

In our scenario with UserController, it now refers to an IUserRepo interface (which costs nothing) rather than referring to the potentially heavy UserRepo that carries a db connection with it everywhere it goes.

在我们使用UserController的场景中，它现在指的是IUserRepo接口(不花一分钱)，而不是指可能很重的UserRepo ，它随处都带有数据库连接。

If we wish to test the controller, we can satisfy the UserController's need for an IUserRepo by substituting our db-backed UserRepo for an in-memory implementation. We can create one like this:

如果要测试控制器，则可以通过将数据库支持的UserRepo为内存中的实现来满足UserController对IUserRepo的需求。 我们可以这样创建一个：

class InMemoryMockUserRepo implements IUserRepo { ... // implement methods and properties
}

方法论 (The methodology)

Here's my thought process for keeping code testable. It all starts when you want to create a relationship from one class to another.

这是我保持代码可测试的过程。 当您要创建一个类到另一个类的关系时，一切就开始了。

Start: You want to import or mention the name of a class from another file.

开始：您想从另一个文件导入或提及一个类的名称。

Question: do you care about being able to write tests against the source class in the future?

问题：您是否担心将来能够针对源类编写测试？

If no, go ahead and import whatever it is because it doesn't matter.

如果不是 ，请继续导入，因为这无关紧要。

If yes, consider the following restrictions. You may depend on the class only if it is at least one of these:

如果是 ，请考虑以下限制。 您只能依赖于至少一个以下类：

• The dependency is an abstraction (interface or abstract class).
  依赖关系是一个抽象(接口或抽象类)。

• The dependency is from the same layer or an inner layer (see The Dependency Rule).

  依赖关系来自同一层或内部层(请参阅Dependency Rule )。

• It is a stable dependency.

  这是一个稳定的依赖关系 。

If at least one of these conditions passes, import the dependency- otherwise, don't.

如果这些条件中的至少一个通过，则导入依赖项；否则，不导入。

Importing the dependency introduces the possibility that it will be hard to test the source component in the future.

导入依赖项可能会导致将来很难测试源组件。

Again, you can fix scenarios where the dependency breaks one of those rules by using Dependency Inversion.

同样，您可以使用Dependency Inversion修复依赖项违反其中一项规则的情况。

前端示例(带TypeScript的React) (Front-end example (React w/ TypeScript))

What about front-end development?

前端开发呢？

The same rules apply!

相同的规则适用！

Take this React component (pre-hooks) involving a container component (inner layer concern) that depends on a ProfileService (outer layer - infra).

以涉及依赖于ProfileService (外层-下文)的容器组件 (涉及内层)的React组件(预挂钩)为例。

// containers/ProfileContainer.tsximport * as React from 'react'
import { ProfileService } from './services'; // hard source-code dependency
import { IProfileData } from './models'      // stable dependencyinterface ProfileContainerProps {}interface ProfileContainerState {profileData: IProfileData | {};
}export class ProfileContainer extends React.Component<ProfileContainerProps, ProfileContainerState
> {private profileService: ProfileService;constructor (props: ProfileContainerProps) {super(props);this.state = {profileData: {}}this.profileService = new ProfileService(); // Bad.}async componentDidMount () {try {const profileData: IProfileData = await this.profileService.getProfile();this.setState({...this.state,profileData})} catch (err) {alert("Ooops")}}render () {return (<div>Im a profile container</div>)}
}

If ProfileService is something that makes network calls to a RESTful API, there's no way for us to test ProfileContainer and prevent it from making real API calls.

如果ProfileService可以对RESTful API进行网络调用，则我们无法测试ProfileContainer并阻止它进行真正的API调用。

We can fix this by doing two things:

我们可以通过做两件事来解决此问题：

1.把一个接口在之间ProfileService和ProfileContainer (1. Putting an interface in between the ProfileService and ProfileContainer)

First, we create the abstraction and then ensure that ProfileService implements it.

首先，我们创建抽象，然后确保ProfileService实现了它。

// services/index.tsx
import { IProfileData } from "../models";// Create an abstraction
export interface IProfileService { getProfile: () => Promise<IProfileData>;
}// Implement the abstraction
export class ProfileService implements IProfileService {async getProfile(): Promise<IProfileData> {...}
}

An abstraction for ProfileService in the form of an interface.

接口形式的ProfileService的抽象。

Then we update ProfileContainer to rely on the abstraction instead.

然后，我们更新ProfileContainer以改为依赖抽象。

// containers/ProfileContainer.tsx
import * as React from 'react'
import { ProfileService, IProfileService 
} from './services'; // import interface
import { IProfileData } from './models' interface ProfileContainerProps {}interface ProfileContainerState {profileData: IProfileData | {};
}export class ProfileContainer extends React.Component<ProfileContainerProps, ProfileContainerState
> {private profileService: IProfileService;constructor (props: ProfileContainerProps) {super(props);this.state = {profileData: {}}this.profileService = new ProfileService(); // Still bad though}async componentDidMount () {try {const profileData: IProfileData = await this.profileService.getProfile();this.setState({...this.state,profileData})} catch (err) {alert("Ooops")}}render () {return (<div>Im a profile container</div>)}
}

2.撰写一个ProfileContainer与包含一个有效的一个HOC IProfileService 。 (2. Compose a ProfileContainer with a HOC that contains a valid IProfileService.)

Now we can create HOCs that use whatever kind of IProfileService we wish. It could be the one that connects to an API like what follows:

现在，我们可以创建使用我们想要的任何IProfileService 。 它可能是连接到API的对象，如下所示：

// hocs/withProfileService.tsximport React from "react";
import { ProfileService } from "../services";interface withProfileServiceProps {}function withProfileService(WrappedComponent: any) {class HOC extends React.Component<withProfileServiceProps, any> {private profileService: ProfileService;constructor(props: withProfileServiceProps) {super(props);this.profileService = new ProfileService();}render() {return (<WrappedComponentprofileService={this.profileService}{...this.props}/>);}}return HOC;
}export default withProfileService;

Or it could be a mock one that uses an in-memory profile service as well.

或者它也可以是模拟的，它也使用内存配置文件服务。

// hocs/withMockProfileService.tsximport * as React from "react";
import { MockProfileService } from "../services";interface withProfileServiceProps {}function withProfileService(WrappedComponent: any) {class HOC extends React.Component<withProfileServiceProps, any> {private profileService: MockProfileService;constructor(props: withProfileServiceProps) {super(props);this.profileService = new MockProfileService();}render() {return (<WrappedComponentprofileService={this.profileService}{...this.props}/>);}}return HOC;
}export default withProfileService;

For our ProfileContainer to utilize the IProfileService from an HOC, it has to expect to receive an IProfileService as a prop within ProfileContainer rather than being added to the class as an attribute.

对于我们ProfileContainer利用的IProfileService从HOC，它有希望收到IProfileService作为内道具ProfileContainer而不是被添加到类为属性。

// containers/ProfileContainer.tsximport * as React from "react";
import { IProfileService } from "./services";
import { IProfileData } from "./models";interface ProfileContainerProps {profileService: IProfileService;
}interface ProfileContainerState {profileData: IProfileData | {};
}export class ProfileContainer extends React.Component<ProfileContainerProps,ProfileContainerState
> {constructor(props: ProfileContainerProps) {super(props);this.state = {profileData: {}};}async componentDidMount() {try {const profileData: IProfileData = await this.props.profileService.getProfile();this.setState({...this.state,profileData});} catch (err) {alert("Ooops");}}render() {return <div>Im a profile container</div>}
}

Finally, we can compose our ProfileContainer with whichever HOC we want- the one containing the real service, or the one containing the fake service for testing.

最后，我们可以组成我们ProfileContainer与取其HOC我们want-一个含有真正的服务，或者包含用于测试的假服务之一。

import * as React from "react";
import { render } from "react-dom";
import withProfileService from "./hocs/withProfileService";
import withMockProfileService from "./hocs/withMockProfileService";
import { ProfileContainer } from "./containers/profileContainer";// The real service
const ProfileContainerWithService = withProfileService(ProfileContainer);
// The mock service
const ProfileContainerWithMockService = withMockProfileService(ProfileContainer);class App extends React.Component<{}, IState> {public render() {return (<div><ProfileContainerWithService /></div>);}
}render(<App />, document.getElementById("root"));

I'm Khalil. I'm a Developer Advocate @ Apollo GraphQL. I also create courses, books, and articles for aspiring developers on Enterprise Node.js, Domain-Driven Design and writing testable, flexible JavaScript.

我是哈利勒。 我是Apollo GraphQL的开发人员拥护者。 我还为有抱负的开发人员创建了有关Enterprise Node.js，域驱动设计和编写可测试的，灵活JavaScript的课程，书籍和文章。

This was originally posted on my blog @ khalilstemmler.com and appears in Chapter 11 of solidbook.io - An Introduction to Software Design & Architecture w/ Node.js & TypeScript.

它最初发布在我的博客@ khalilstemmler.com上，并出现在solidbook.io的第11章中-带Node.js和TypeScript的软件设计与体系结构简介 。

You can reach out and ask me anything on Twitter!

您可以在Twitter上向我提问！

翻译自: https://www.freecodecamp.org/news/how-to-write-testable-code/