测试代码怎么做抽象才是有意义的?

本文探讨了在编写前端测试代码时如何平衡抽象与冗余,提出了AHA原则,即避免过度抽象。通过示例展示了过度抽象(ANA)和过度DRY(Don't Repeat Yourself)可能导致的维护难题,并提供了改进方案。建议采用适度的抽象,如使用setup函数创建基础Mock对象,然后在具体测试用例中突出差异,提高测试的可读性和维护性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

哈喽,大家好,我是海怪。

不知道大家在写前端单测的时候,是否有出现测试代码和测试数据重复冗余的情况?然后不得不写一些函数和类来封装他们的。然而,慢慢地会发现:过度的封装会致使你的测试用例变得越来越难读。

那到底在写测试代码时,怎样的封装才是好的封装呢?今天就把 Kent 的这篇 《AHA Testing》 分享给大家~


正片开始

“AHA 编码原则” 指的是 “避免过度的抽象”(Avoid Hasty Abstraction)。我对这如何适用于编写可维护的测试有不一样的感觉。因为我见过太多人写的测试都是在下面这条轴两个极端:要么是 ANA (Absolutely No Abstraction) 完全没有任何抽象,要么是 完全 DRY (Don’t Repeat Yourself) 完全不做任何重复【译注:我觉得这里可以理解为过度抽象】。(ANA 是我现在起的名)

要写出一份高维护性测试代码的关键就是在上面这条轴上找一个最完美的平衡点。

ANA Testing

一个我见过最好的 “完全不做抽象” 的例子就是给 Express 的 Route Handler 写测试。为了能让你理解我这里说的 “用 ANA 写测试是不好的”,这里给你一个经典的样例,你来维护好它的代码库和测试用例。可能你现在会觉得这些测试用例也能保障代码质量,也还好。不过这样的用例真的没问题么?先让我们来看看这些测试代码来找出下面 Route Handler 中的不同之处吧。

别花太久的时间哦

import * as blogPostController from '../blog-post'

// load the application-wide mock for the database.
// I guess that means this is AANA (Almost Absolutely No Abstraction)
// but I didn't want to write out a whole db mock for this blog post 😅
jest.mock('../../lib/db')

test('lists blog posts for the logged in user', async () => {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 51.507351,
      longitude: -0.127758,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
  }
  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: expect.arrayContaining([
      expect.objectContaining({
        title: 'Test Post 1',
        subtitle: 'This is the subtitle of Test Post 1',
        body: 'The is the body of Test Post 1',
      }),
    ]),
  })
})

test('returns an empty list when there are no blog posts', async () => {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 31.230416,
      longitude: 121.473701,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
  }
  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: [],
  })
})

找到其中的差别了么?这里的差别是:第一例子能够返回一个 Post,而在第二个用例中不返回这个 Post!那么到底是什么导致两者的差别呢?还有,为什么要在第一个用例里 blogPostController.loadBlogPosts(req, res, next) 调用的 res.json 里要返回 Post,而第二个用例却没有返回呢?

如果你想不出这些问题的答案。没关系,等会再说。如果你搞懂了,说明你很适合玩《大家一起来找猹》这个流。如果都像上面这样写测试,那么写出来的用例很难让别人阅读和维护。

假如现在有 20 多个这样的测试用例放在一个文件里,你是不是看着很难受?你可能会说:哪有那么夸张?别笑,像这样的我见太多了。我举个例子:

  • 一个新人刚到新团队
  • 然后被叫去加个测试用例
  • 复制一下以前的测试代码,在上面改改,感觉没什么问题就提交了
  • Review 的人一看:测试通过了,代码应该没问题就 Approve 了
  • PR 合并

所以,为了更好地处理这种情况,你可以思考以下两个问题:

你的测试用例是否能够很快让人看懂它们之前的差异以及这些差异的来源。

绝对不要写 “完全没抽象” 的测试代码。

DRY Testing

我现在没法给一个很好的 DRY 测试代码的例子。只需要知道:当想把所有东西都要弄成 DRY 的时候,测试就会变得非常难以维护了,比如:

  • 一个新人刚到新团队
  • 他被叫去加个测试用例
  • 复制以前的测试代码,然后在测试工具函数中加了一行 if 语句来通过测试
  • Review 的人一看:测试通过了,代码应该没问题就 Approve 了
  • PR 合并

在 DRY 测试中,我见的很多的另一种情况就是:滥用 describeit 的嵌套以及 beforeEach。你越是想用嵌套来做变量的共享,越是难让人搞懂测试代码的逻辑。关于这个问题,可以看我的 [《Test Isolation with React》])(https://kentcdodds.com/blog/test-isolation-with-react) 这篇文章。


以下为译注内容。 这里作者没有给一个很好的例子,我这里稍做补充一下。举下面这个例子:

import { getUserById } from 'src/db/user';
import { mockUser, mockAttributes } from 'tests/utils/constants';
import { insertUser } from 'tests/utils/db';

describe('测试 DB', () => {
  it('测试 getUserById', async () => {
    const user = {
      id: '123',
      ...mockUser,
      ...mockAttributes,
    }
    
    await insertUser(user);
    
    const resultUser = await getUserById('123');
    
    expect(resultUser).toEqual(user);
  })
})

我们把 mockUser, mockAttributes 以及 insertUser 都放在 tests/utils 下了,这样去构造测试用例很容易会出现过度抽象。因为对于第一次看这个用例的人来说,他得先去找 tests/utils/contants 下的 user 相关的数据,然后再去 tests/utils/db 下找 insertUser 的具体实现,再然后才能拼凑出一个完整的 user 输入内容。

在最后的 toEqual 里也要回过头来看 user 的内容是啥,这就导致阅读用例的人会有比较高的心智负担,他大脑得有一个内存时刻存放着这个 user 的样子,这样的用例就变得很难让人跟上了,特别是在一些用例非常多的测试文件中,这种心智负担会变得越来越重。

所以,这里更推荐是可以在前面加一个 setup 函数用于生成对应的 user 内容,然后再在具体的用例中 用非常明显的方式 去添加这个用例的 “独特之处”(比如名字变了之类的)

import { getUserById } from 'src/db/user';
import { getMockUser } from 'tests/utils/user';
import { insertUser } from 'tests/utils/db';

const setup = () => {
  return getMockUser();
}

describe('测试 DB', () => {
  it('测试 getUserById', async () => {
    const mockUser = setup();
    
    mockUser.name = 'Jack';

    await insertUser(mockUser);

    const resultUser = await getUserById('123');

    expect(resultUser.name).toEqual('Jack');
  })
})

这里依然把 getMockUserinsertUser 放在 tests/utils 中了,因为别的地方也有可能会用到,还是得做适量的抽象。不过,我们这里把 mockUser.name = 'Jack' 放在第二行,那对于第一次看的人来说就知道:这个用例的重点要关注 name 这个字段。

而后面的 toEqual('Jack') 也很清晰地让阅读用例的人知道:你现在期望的结果就是 'Jack',而不是 mockUser.name,因为如果写变量的话,会很人很不放心:“万一这个变量被改了呢?”

总的来说,我们不要过度代入开发的视角,而要以 文档阅读者 的角度去编写自己的用例,用例可读性应该优先于代码可读性。

译注结束。


AHA Testing

上面第一个例子绝对是抽象的灾难(不过这也可以作为 AHA 编程思路的一个参考方向)。现在一起来把上面的测试写得更让人容易理解吧。首先我们来理清楚这两个用例的不同之处。

import * as blogPostController from '../blog-post'

// load the application-wide mock for the database.
jest.mock('../../lib/db')

function setup(overrides = {}) {
  const req = {
    locale: {
      source: 'default',
      language: 'en',
      region: 'GB',
    },
    user: {
      guid: '0336397b-e29d-4b63-b94d-7e68a6fa3747',
      isActive: false,
      picture: 'http://placehold.it/32x32',
      age: 30,
      name: {
        first: 'Francine',
        last: 'Oconnor',
      },
      company: 'ACME',
      email: 'francine.oconnor@ac.me',
      latitude: 51.507351,
      longitude: -0.127758,
      favoriteFruit: 'banana',
    },
    body: {},
    cookies: {},
    query: {},
    params: {
      bucket: 'photography',
    },
    header(name) {
      return {
        Authorization: 'Bearer TEST_TOKEN',
      }[name]
    },
    ...overrides,
  }

  const res = {
    clearCookie: jest.fn(),
    cookie: jest.fn(),
    end: jest.fn(),
    locals: {
      content: {},
    },
    json: jest.fn(),
    send: jest.fn(),
    sendStatus: jest.fn(),
    set: jest.fn(),
  }
  const next = jest.fn()

  return {req, res, next}
}

test('lists blog posts for the logged in user', async () => {
  const {req, res, next} = setup()

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: expect.arrayContaining([
      expect.objectContaining({
        title: 'Test Post 1',
        subtitle: 'This is the subtitle of Test Post 1',
        body: 'The is the body of Test Post 1',
      }),
    ]),
  })
})

test('returns an empty list when there are no blog posts', async () => {
  const {req, res, next} = setup()
  req.user.latitude = 31.230416
  req.user.longitude = 121.473701

  await blogPostController.loadBlogPosts(req, res, next)

  expect(res.json).toHaveBeenCalledTimes(1)
  expect(res.json).toHaveBeenCalledWith({
    posts: [],
  })
})

来说说第一个和第二个用例不同之处在哪?第一个用例的用户在 London,第二个则在 Shanghai

只要稍微添加一点点抽象代码,我们就可以很清晰地分清用例之前的输入和输出的不同,这样的测试代码就会更容易让人理解和维护。

用 AHA 思想来测 React

当测 React 组件时,我一般都会有一个 renderFoo 的函数专门用来充当 setup 的作用。比如:

import * as React from 'react'
import {render, screen} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import LoginForm from '../login-form'

function renderLoginForm(props) {
  render(<LoginForm {...props} />)
  const usernameInput = screen.getByLabelText(/username/i)
  const passwordInput = screen.getByLabelText(/password/i)
  const submitButton = screen.getByText(/submit/i)
  return {
    usernameInput,
    passwordInput,
    submitButton,
    changeUsername: value => userEvent.type(usernameInput, value),
    changePassword: value => userEvent.type(passwordInput, value),
    submitForm: () => userEvent.click(submitButton),
  }
}

test('submit calls the submit handler', () => {
  const handleSubmit = jest.fn()
  const {changeUsername, changePassword, submitForm} = renderLoginForm({
    onSubmit: handleSubmit,
  })
  const username = 'chucknorris'
  const password = 'ineednopassword'
  changeUsername(username)
  changePassword(password)
  submitForm()
  expect(handleSubmit).toHaveBeenCalledTimes(1)
  expect(handleSubmit).toHaveBeenCalledWith({username, password})
})

如果像上面只有两、三个测试用例,或者测试代码很短的话,我会觉得这有点过早优化了。但如果你的用例都是各自有一些细微区别(比如错误状态等),那么像这样去做抽象就是很好的。

Nesting 嵌套

建议看 《https://kentcdodds.com/blog/avoid-nesting-when-youre-testing》 这篇文件。

jest-in-case 和 test.each

如果你只是做纯函数的测试,那么你很幸运,因为它们都是最容易测的。你完全可以通过简单的抽象来简化测试代码,让它们在调用时更明显地展示输入和输出内容。

比如:

import add from '../add'

test('adds one and two to equal three', () => {
  expect(add(1, 2)).toBe(3)
})

test('adds three and four to equal seven', () => {
  expect(add(3, 4)).toBe(7)
})

test('adds one hundred and two to equal one hundred two', () => {
  expect(add(100, 2)).toBe(102)
})

我们还可以用 jest-in-case 更优雅的写法来实现:

import cases from 'jest-in-case'
import add from '../add'

cases(
  'add',
  ({first, second, result}) => {
    expect(add(first, second)).toBe(result)
  },
  [
    {first: 1, second: 2, result: 3},
    {first: 3, second: 4, result: 7},
    {first: 100, second: 2, result: 102},
  ],
)

对这样简单的用例,我可能不会用这样方式写,不过,能直接在数组后面添加输入和输出就能添加更多的测试用例,感觉还是挺爽的。类似这类思路的一个很好的例子就是:rtl-css-js 的测试用例。其它代码贡献者会发现用这样的结构来添加用例简直不要太爽!

当然这也可以用在一些非纯函数的情况,不过可能要做更多的抽象了。(这有个例子,虽然不是很好,但是我觉得还凑合

我个人是很喜欢 jest-in-case 的,不过 jest 已经内置了 test.each 了,应该会对你有所帮助。

总结

虽然我们的测试代码可以通过起更好的用例名,写更多的注释来提升观感和可读性,但是,如果有一个简单的 setup 抽象函数(也叫做 Test Object Factory),就可以不需要它们了。所以,我的观点是:高质量且有意义的代码抽象能有效地减少编写和维护测试代码的成本。


好了,这篇外文就给大家带到这里了。总的来说,我是认可作者的观点的,因为我们写单测时难免会遇到要构造一堆 Mock 对象、实例的情况,而且对不同的测试用例 Mock 内容可能仅有细微差别。

而如果你把这些搞得太抽象,比如放在 tests/utils 来生成对象的话,又会导致太抽象而难以理解,对阅读用例的人来说有着非常高的心智负担。所以最好的方式还是在当前测试文件中,写一个 setup 函数来生成基础的 Mock 对象,然后再在对应用例中做细微差别的调整即可,并尽量把差异化展现出来。这不仅能让阅读者跟上用例的节奏,也能对用例的输入和输出也一目了然。

如果你喜欢我的分享,可以来一波一键三连,点赞、在看就是我最大的动力,比心 ❤️

<think>嗯,用户想知道如何用Verilog编写伪代码以及设计流程。首先,我需要回忆一下Verilog的基本结构和伪代码的作用。伪代码主要是用来描述算法逻辑,不涉及具体语法,而Verilog是硬件描述语言,用于设计数字电路。所以,用户可能希望了解如何将伪代码转化为Verilog代码,并了解整个设计流程。 根据引用[1],伪代码的目标是解释程序每一行该做什么,帮助构建代码。那在Verilog中,伪代码可能用于模块的功能描述,比如组合逻辑或时序逻辑。需要明确伪代码的步骤,然后对应到Verilog的模块、端口、always块等结构。 接下来,设计流程部分。用户可能想知道从需求到仿真、综合的整个流程。引用[3]提到仿真验证是关键步骤,所以需要包括仿真和测试。此外,引用[2]提到流水线设计中的模块划分,可能相关的是模块分解、功能实现、连接等步骤。 用户的问题还涉及到伪代码的编写流程。可能需要先确定功能需求,再用伪代码描述,然后转化为Verilog的结构,比如状态机、组合逻辑等。例如,引用[4]中的例子是用函数统计0的个数,伪代码中的循环和条件判断对应Verilog中的for循环和if语句。 另外,Testbench的编写也很重要,引用[5]提到测试脚本的艺术,所以设计流程中应包括测试用例的编写和仿真验证。需要确保每个模块的功能正确,再进行集成和综合。 可能需要注意Verilog的语法,比如模块声明、端口定义、always块的使用,以及阻塞和非阻塞赋值的区别。伪代码中的步骤可能需要用Verilog的always块中的逻辑来实现,特别是时序逻辑需要时钟和复位信号。 用户可能存在的疑问是如何将伪代码的算法步骤映射到硬件结构,比如使用状态机还是组合逻辑。例如,如果伪代码中有循环,可能需要用状态机或者生成块来实现,或者分解为多个时钟周期。 总结下来,回答需要分步骤:伪代码编写要点,设计流程(模块划分、代码实现、仿真测试、综合实现),并给出示例和注意事项。同时,要引用相关的引用内容,比如伪代码的目的[^1],仿真验证的重要性[^3],测试用例的方法[^5]等。</think>### Verilog伪代码编写流程及设计步骤 #### 一、Verilog伪代码编写要点 1. **功能抽象**:将算法逻辑用自然语言描述,例如计数器、状态机或数据处理的流程。 - 例:统计输入数据中"0"的个数(引用[^4]) - 伪代码示例: ``` 初始化计数器count=0 遍历输入数据每一位: if 当前位为0 → count+1 输出count ``` 2. **模块化映射**: - 将伪代码中的逻辑映射到Verilog模块,明确输入输出端口。 - 示例模块声明: ```verilog module count_zeros ( input [7:0] x, output reg [3:0] out ); ``` 3. **时序/组合逻辑划分**: - 组合逻辑用`always @(*)`块,时序逻辑用`always @(posedge clk)`块。 - 示例: ```verilog always @(*) begin count = 0; for (i=0; i<=7; i=i+1) if (x[i] == 1'b0) count = count + 1; end ``` --- #### 二、Verilog设计流程(基于工程实践) 1. **需求分析** - 明确功能目标(如实现流水线CPU[^2]或特定算法)。 - 定义输入输出信号及时序要求。 2. **模块划分与伪代码设计** - 将系统拆分为子模块(如ALU、寄存器、控制器)。 - 为每个模块编写伪代码流程: ```verilog // 示例:ALU伪代码 if (opcode == ADD) → 输出a+b else if (opcode == SUB) → 输出a-b ``` 3. **代码实现** - 根据伪代码编写可综合的Verilog代码: ```verilog case (opcode) ADD: out = a + b; SUB: out = a - b; default: out = 0; endcase ``` 4. **仿真验证** - 编写Testbench模拟输入信号,验证功能正确性(引用[^3])。 - 示例测试激励: ```verilog initial begin x = 8'b10100101; #10; $display("Count of zeros: %d", out); end ``` 5. **综合与实现** - 使用EDA工具生成门级网表,检查时序和面积约束。 6. **物理设计** - 布局布线(针对FPGA或ASIC),生成最终配置文件。 --- #### 三、关键注意事项 1. **语法规范**: - 变量声明需明确位宽(如`reg [3:0] count`)。 - 避免组合逻辑中的锁存器(完整覆盖所有条件分支)。 2. **可读性优化**: - 使用注释标注伪代码代码的对应关系。 - 模块命名需体现功能(如`data_extend`、`pipeline_reg`)。 3. **可测试性设计**: - 添加调试信号(如流水线各级状态输出[^2])。 - 采用层次化验证:先模块级,再系统级。 --- #### 示例:伪代码到Verilog的完整转换 ▌伪代码描述: ``` 功能:检测输入信号上升沿 当当前信号为1且上一周期为0时,输出脉冲信号 ``` ▌Verilog实现: ```verilog module edge_detect ( input clk, rst, input signal, output reg pulse ); reg signal_prev; always @(posedge clk) begin if (rst) signal_prev <= 0; else begin signal_prev <= signal; pulse <= (signal & ~signal_prev); // 比较当前值与历史值 end end endmodule ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

写代码的海怪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值