课程导学：为什么需要单元测试与无障碍测试
大家好，我是这个课程的讲师。在开始之前，我想先聊一个我亲眼见过的问题——
几年前我参与一个金融类的前端项目，测试覆盖率报告显示“99%”，看起来很漂亮对吧？但上线后，盲人用户反馈所有表单都读不出来，因为 aria 标签压根没写。单元测试全过了，可无障碍测试完全没覆盖。那个周末我们整个小组加班补 aria-label，补 focus 顺序……嗯，从那时起我就一直在想：为什么不能把无障碍检查直接塞进单元测试里？
这个课程，就是要把「单元测试」和「无障碍测试」这两件事真正融合起来，给出一个可落地的分层方案。别担心，你不需要一下子掌握所有东西，我们一步步来。
为什么需要单元测试
单元测试，说白了就是给函数、组件、方法写“体检报告”。它能在代码改动的第一时间告诉你：改坏了没有。
- 提前发现低级错误——我有个习惯：每写一个纯函数就顺手写个 test case。很多时候 bug 不是逻辑复杂，而是边界条件没处理（比如空数组、null 值）。
- 保护重构安全——你想想看，没有单元测试的代码就像没有护栏的边墙，动一块砖就可能塌。我在项目中遇到过多次，改了一个工具函数，结果三个模块报错，幸好测试提前拦住了。
- 文档即代码——好测试本身就是活文档，告诉后来的人“这个函数期望输入什么，输出什么”。
💡 个人小习惯：我一般不会等到所有功能写完再补测试，而是先写测试框架，再写函数体。TDD（测试驱动开发）虽然刚开始有点别扭，但习惯后你会觉得真香。
为什么需要无障碍测试
很多人觉得无障碍（a11y）是「加分项」，不是「必选项」。但我得说，这想法过时了。法律要求、用户体验、甚至 SEO 都会受它影响。
- 法律风险——欧美很多国家已经立法，网站不符合 WCAG 标准可能被起诉。别等到收到律师函再重视。
- 用户群体比你想象的大——全球有超过 10 亿人有某种形式的残障。你想想看，你的产品如果把这些人拒之门外，损失的不只是用户，还有社会声誉。
- 手动测试太慢——我曾经让测试同学手动跑一遍无障碍检查，一个页面要 30 分钟，而且每次改版都得重测。效率极低。所以我们需要自动化，需要把它嵌入到单元测试流程中。
⚠️ 避坑指南：我曾经犯过一个错误：只依赖工具自动检测，比如 axe-core。但工具能检出的是语法问题，比如缺少 aria-label，但无法判断语义是否合理。比如一个 div 加了 role="button"，工具可能不报错，但屏幕阅读器用户会觉得莫名其妙。所以分层策略非常重要。
课程目标
学完这门课程，你将掌握以下能力：
| 目标 | 说明 |
|---|---|
| 理解分层方法 | 不是一把抓，而是按层（代码层、组件层、集成层）渐进式覆盖 |
| 上手落地框架 | 结合 Jest、Testing Library、axe-core 等工具写出可维护的无障碍测试 |
| 避坑经验 | 我会分享 5 年实战中遇到的典型问题，帮你少走弯路 |
| 建立质量思维 | 从“写完再测”变成“写的时候就想怎么测” |
学习路径
我把整个课程分成三个大阶段，每个阶段都包含理论和动手练习：
- 基础夯实（第1-10章）——单元测试核心概念、无障碍标准基础、工具链搭建。这部分我会带着你写最简单的测试用例。
- 分层实战（第11-20章）——按照分层方法，逐层攻破：纯逻辑函数测试 → 组件渲染测试 → 交互行为测试 → 无障碍断言集成。
- 进阶与体系化（第21-30章）——CI/CD 集成、性能优化、自定义规则、团队规范推广。这部分会涉及真实项目案例。
📌 核心建议：不需要一开始就啃完所有章节。我的建议是每看完一章，立刻在自己的项目里试一试，哪怕只改一个文件。做中学才是最快的。
看到这个图，你可能已经猜到了整个课程的脉络。我们会从“为什么”开始，建立认知，然后一步步落到代码。我个人非常不喜欢只讲理论不讲实操的课程，所以每个知识点我都会给你一个可以运行的示例。