DEV Community 👩‍💻👨‍💻

Towry
Towry

Posted on

简单方法写高质量的代码

首先,要知道单元测试是怎么写的。

下面是一个要测试的函数:

function add(a: number; b: number;) {
   return a + b;
}
Enter fullscreen mode Exit fullscreen mode

我们要写单元测试,保证这个函数是OK的:


describe('add', () => {
  it('should work', () => {
     expect(add(1, 2)).toBe(3);
     expect(add(4, 4)).toBe(8);
  })
})
Enter fullscreen mode Exit fullscreen mode

如果我们给的测试用例都能通过,那么说明我们的方法是安全可用的。

所以,在你写模块,写函数的时候,如果你的模块,函数,能被很容易的单元测试,那么你写的模块,函数就是80%安全可用的,出现bug的几率很少的。

但是,假如我们把上面的函数改变下:

import { addByRemote } from './api.js';

async function add(a: number; b: number) {
  return await addByRemote(a, b);
}
Enter fullscreen mode Exit fullscreen mode

现在这个函数可以很方便的被单元测试吗?答案是不能。因为它依赖了一个接口调用,这个依赖的实现逻辑复杂度是不能确定的,但是我们把它耦合到了我们的add方法里了,那么我们的add方法逻辑就包含了这个接口的逻辑。

我们的add只是个例子,里面的逻辑很简单,但是想像这是个很复杂的业务逻辑,我们要写单元测试,保证这个业务逻辑是OK的,但是因为这个接口调用,我们的业务逻辑变得更复杂更臃肿了。我们的业务逻辑只是依赖这个接口的结果,不想关心接口里面的逻辑的。你如果把这个接口的结果看成函数的参数,就很好理解了。

现在这个 add 函数无法进行单元测试的,因为我们很难模拟这个 http 接口请求,我们可以称这个接口请求为副作用。如果这样的副作用变得多了,那么这个函数变得更加不稳定,更加难于测试了。

那么怎么处理这样的情况呢?

方法1: 把接口的结果作为参数传入我们的函数。
方法2: 通过依赖注入的方式,将这个API注入进去。这样的好处是,我们在单元测试的时候,可以注入一个我们模拟的函数作为这个API。

结论:如果你写的函数,不能很容易的被单元测试,那么你就需要考虑你的函数里面的依赖关系了,否则你写的就是一个很不好的代码。

Top comments (0)

Let's team up together 🤝

We're Hiring

We're hiring for a Senior Full Stack Engineer to join the DEV team. Want the deets? Head here to learn more about who we're looking for.