原生CSS无法直接单元测试因其无运行时和可断言接口；Sass测试需通过sass-true验证函数或编译后CSS快照比对，不支持混入副作用测试，且须正确配置includePaths与加载路径。
为什么原生 CSS 不能直接写单元测试
因为 CSS 本身没有运行时、没有函数调用栈、不暴露可断言的接口——jest 或 cypress 拿不到“这个 class 是否真的应用了 padding: 12px”，只能检查 DOM 结构或计算样式。Sass 更麻烦：它在构建期就被编译成 CSS，测试对象其实是编译结果，不是源码逻辑。
所以所谓“Sass 单元测试”，本质是：对 _mixins.scss 输出的 CSS 做快照比对，或对 @function 返回值做断言。核心路径只有两条：
- 用
node-sass/dart-sassAPI 编译片段 + 提取生成 CSS，和预期比对 - 用
sass-true（专为 Sass 函数/混入设计）在 Dart Sass 环境下执行并断言
sass-true 是目前最靠谱的 Sass 函数测试方案
sass-true 把测试写在 .scss 文件里，用 @include test-module 和 @include test 描述用例，再通过 CLI 运行。它不依赖 JS 测试框架，直接跑在 Sass 编译器上，能真实验证 @function 行为。
常见错误现象：Cannot find module 'sass-true' —— 因为它是 Sass 包，不是 npm 包；必须用 sass --load-path=node_modules/sass-true 引入，不能 require()。
立即学习“前端免费学习笔记（深入）”；
- 测试文件必须以
_test.scss命名，且 importTrue后调用@include test-report() -
@function px-to-rem($px) { @return $px / 16 + rem; }的测试要写成@include test("px-to-rem returns 1.5rem for 24px") { @include assert-equal(px-to-rem(24), 1.5rem); } - 不支持测试
@mixin的副作用（比如是否插入了某段 CSS），只适合纯函数逻辑
测试 Mixin 输出的 CSS 必须走编译+解析路径
想验证 @mixin flex-center { display: flex; justify-content: center; align-items: center; } 是否真输出这三行？没法用 sass-true。得用 dart-sass JS API 编译一个最小 SCSS 片段，再解析生成的 CSS 字符串。
容易踩的坑：renderSync({ file: "_test.scss" }) 不会自动加载 @import 的依赖，必须显式传 includePaths: ["node_modules", "src/styles"]；否则报错 File to import not found。
- 用
compileString而非compile，避免读文件 IO，更快更可控 - 测试内容应包裹在匿名类中，例如
.test { @include flex-center; }，防止污染全局 CSS - 正则匹配输出 CSS 要小心空格和换行，推荐用
normalizeWhitespace工具函数统一处理
Cypress 或 Playwright 只能测最终渲染效果，不是 Sass 单元测试
有人把 cypress 里写 cy.get(".btn").should("have.css", "padding", "12px") 当成 Sass 测试——这是端到端验证，和 Sass 无关。它测的是构建后 CSS 是否被正确加载、是否被更高优先级规则覆盖、是否受浏览器默认样式干扰。
这类测试有意义，但属于另一层质量保障。它无法告诉你：button-size($level: md) 函数在 $level: lg 时返回了错误值，或者 @mixin theme-dark 忘记重置某个 border-color。
- 如果 Sass 源码改了但没更新快照，Cypress 不会失败；它只认最终渲染结果
- CI 中字体加载延迟、系统缩放、暗色模式开关都可能让
getComputedStyle返回意外值 - 真正要锁定 Sass 逻辑，还是得回到
sass-true或编译断言
复杂点在于：Sass 测试从来不是单点工具链的事。你得同时维护函数测试、混入输出快照、组件级视觉回归，三者缺一不可——但最容易被忽略的，是混入输出测试里对 includePaths 和 functions 配置的同步管理。
