我在团队内部提倡禁用单元测试

先说结论：
在绝大部分的业务前端开发中，写单元测试的收益非常小，但是带来的维护成本却非常大，请不要再写单元测试感动自己，为难同事了。

现在很多单元测试的教程都是那种很简单的比如，测个 1+1=2，这需要测吗？下面这段代码已经出现过很多次了，纯纯的误导人。

const sum = (a,b) => a+b
it('1+1=2',()=> {
expect(sum(1,1)).toBe(2)

})

稍微上点复杂度，来写个组件的单测，比如一个用户信息展示组件，叫 UserInfoBlock，支持设置头像的大小，点击名字支持跳转到个人主页，组件代码大致长这样

interface UserInfoBlockProps {
name: string
size: 16 | 24
id: string
icon: string

}
export const UserInfoBlock:FC<UserInfoBlockProps> = (props) => {
const navigate = useNavigate()
return <div 
class='xxxxxx' 
style={{width: props.size}} 
onClick={() => {navigate(`/user/${props.id}`)}}>
<img src={props.icon}/>

                {props.name}
</div>

}

然后开始给组件写单测，先测头像大小的功能

import { UserInfoBlock, UserInfoBlockProps } from './user-info-block'
import { fireEvent, render, screen } from '@testing-library/react'
describe('UserInfoBlock 组件单测', () => {
const userInfo:UserInfoBlockProps = {
name: '张三',
icon:'https://xxx.png',
id:'abcd1234',
size: 16

    }
const userInfoLarge:UserInfoBlockProps = {
name: '张三',
icon:'https://xxx.png',
id:'abcd1234',
size: 24

    }
describe('展示默认头像大小', () => {
const component = render(<UserInfoBlock {...userInfo}/>)
it('img 标签的宽度为 16px', () => {
expect(screen.getByTag('img').style.width).toBe(16)

        })

    })
describe('展示large头像大小', () => {
const component = render(<UserInfoBlock {...userInfoLarge}/>)
it('img 标签的宽度为 24px', () => {
expect(screen.getByTag('img').style.width).toBe(24)

        })

    })

})

接下来测一下跳转，因为用了 react-router，所以在渲染组件的时候必须包裹一下 RouterProvider

...
describe('点击可以跳转', () => {
const component = render(<MemoryRouter>
<UserInfoBlock {...userInfoLarge}/>
</MemoryRouter>

        )

        fireEvent.click(component.div)
it('url 会变成 user/abcd1234', () => {
expect(location.pathname).toBe('user/abcd1234')

        })

    })

...

这个组件的测试就写完了，看起来挺有用，但实际没啥用。

首先这个测试的收益不高，因为这是一个很简单的组件，五分钟写完，但是写这个测试需要翻倍的时间，因为需要构造数据，之前没有经验不知道要加 MemoryRouter，jest 测 location 对象不方便，还要 mock 一下。等把这一套搞完了才能跑通，这就好像你疯狂锻炼，练出麒麟臂，就是为了举自拍杆举的稳一点。如果组件内要发请求，要做的准备工作就更加多了。

其次，user/abcd1234是什么，断言这个没用，因为别人改了链接，你的测试也一样会过，应该断言成功的打开了用户主页，比如断言一个必定会存在的文字expect(screen.getByText('用户详情')).toBeInDocument()这才能证明真的打开了用户主页。

1+1 什么时候不等于 2。头像设置 16px，什么时候不会是 16 px。什么时候点击不跳转到用户主页。肯定是有人修改了这里的业务逻辑才会这样，只有在做产品需求，代码优化的时候才会去改以前的代码。那么这时，这段测试对接手这段代码的人就是负担。

假设我接到需求，用户主页url 变了，改成 user?id=xxx。我心想这个简单，一秒钟解决，提了 pr 发现测试挂了，然后我就得把测试也改一下。

如果一段测试代码在我每次修改需求的时候都要改，甚至有的时候还会为了便于测试在业务代码中留一些后门，那这个测试就是纯纯的副作用。

大家肯定深有体会，一般一个模块自己不会出问题，但是多个模块组合起来就很容易出问题了，所以测试的重点不应该是一个组件内部各种细节，而应该测这个组件在被使用的地方是否正确。

举个例子，比如在一个列表里面，使用头像为 24px 的用户组件，然后有一天出 bug 了，说这里变成 16 了。那这会是组件的 bug 吗，这肯定是使用的地方没有用对。所以应该要测试的是这里。如果有个测试断言了在列表中用户头像必须为 24px，即使没有组件的单测，这个组件也不会被改坏，因为上层已经覆盖到了。

什么是好的测试？

那么怎么写出这样的测试呢？答案就是写集成测试，集成测试说白了就是一个超级大的单测，之前测试 render 的是一个组件，现在直接 render(<App/>)，将路由跳转，请求 mock，fake数据库等等都统一处理。可以将上面写的测试简单的改为

import { creatAppContext, AppContext } from './app-test-context'
describe('S: 测试头像组件', () => {
let _:AppContext
beforeEach(() => {

        - = creatAppContext()

    })
describe('W: 去用户列表也', () => {
beforeEach(() => {

            _.click(screen.getByText('查看用户列表'))

        })
it('T: 列表页有十个用户，用户头像是 24px', ()=>{
expect(screen.getAllByTestid('user-item').length).toBe(10)
expect(screen.getAllByTestid('user-item')[0].img.style.width).toBe(24)

        })
describe('W: 点击第一个用户', () => {
beforeEach(() => {

                _.click(screen.getAllByTestid('user-item')[0])

            })
it('T: 打开了用户主页', () => {
expect(screen.getByText('用户详情')).toBeInDocument()

            })

        })

    })

})

关于怎么写好测试可以展开的点实在太多了，就不过多阐述，想要了解的朋友可以查看我的主页，之前专门出过一些列文章详细的讲这些事情。