Sass单元测试只有两条可靠路径：用sass-true测@function返回值，或用Dart Sass JS API编译+字符串比对测@mixin输出；前者需_test.scss文件、@use "pkg:sass-true"及assert-equal断言，后者须包裹混入于选择器内并逐字符比对CSS。
不能靠 Jest 或 Cypress 直接测 Sass 源码，因为 Sass 在构建期就编译成 CSS，没有运行时；所谓“自动化单元测试”，实际只有两条可靠路径：用 sass-true 测函数返回值，或用 Dart Sass JS API 编译 + 字符串比对测 @mixin 输出。
用 sass-true 测试 @function 返回值
sass-true 是目前唯一被 Dart Sass 官方生态接纳的纯 Sass 测试方案，它不依赖 Node.js 运行时，直接在 Sass 编译器里执行断言。但只适用于有明确返回值的 @function，比如单位转换、颜色计算等。
- 测试文件必须以
_test.scss命名，且开头要@use "pkg:sass-true" as *;（不是require()） - 调用
@include test("描述") { @include assert-equal(px-to-rem(24), 1.5rem); }，注意第二个参数必须是 Sass 值（如1.5rem），不能是字符串"1.5rem" - 常见报错
Cannot find module 'sass-true'，是因为没配--load-path=node_modules/sass-true；CLI 跑的话加这个参数，JS API 跑则要在compileString()的loadPaths里传入绝对路径 - 不支持测试
@mixin的副作用，哪怕里面只有一行color: red——sass-true根本不捕获 CSS 输出流
用 Dart Sass JS API 测试 @mixin 输出的 CSS
想验证 @mixin flex-center 是否真生成 display: flex; justify-content: center; align-items: center;，只能走编译后解析路径。核心是用 compileString() 调用最小 SCSS 片段，再比对生成的 CSS 字符串。
- 必须把混入包裹在匿名类里，例如
.test { @include flex-center; }，否则输出的是无选择器的声明块，无法提取有效 CSS - 用
compileString()而非compile()，避免读文件 IO；传参时显式指定loadPaths: [path.resolve('node_modules', 'your-sass-lib')]，否则@use或@import会失败 -
@include expect里的 CSS 必须和实际输出逐字符一致：空格、换行、分号位置都不能差——Dart Sass 默认压缩输出（单行无空格），所以@include expect也得写成单行 - 如果混入内部用了
@if分支，测试必须覆盖所有路径；漏掉一个，compileString()输出就不同，比对直接 fail
为什么不能用 Jest / Cypress 直接测 Sass？
因为原生 CSS 没有运行时、没有可调用接口、不暴露可断言的状态。Jest 拿不到 “这个 class 是否真的应用了 padding: 12px”，它只能查 DOM 结构或 getComputedStyle()，而后者依赖浏览器环境，且测的是最终渲染结果，不是 Sass 逻辑本身。
立即学习“前端免费学习笔记（深入）”；
- 你写的
@function rem-to-em($rem)在编译后就消失了，Jest 根本看不到它 - Cypress 可以访问
document.styleSheets，但拿到的是已合并、已压缩、可能被其他规则覆盖的 CSS 文本，无法还原到某个@mixin的原始输出 - 有人试图用
jest-css-modules模拟，但那只是 mock 类名映射，和 Sass 编译逻辑完全无关 - 真正能测 Sass 行为的，只有在 Sass 编译器上下文里运行的工具，比如
sass-true或自定义compileString()流程
容易被忽略的路径与格式陷阱
绝大多数测试失败不是逻辑错，而是路径没对上、格式没对齐。尤其当项目用了 @use + pkg: 协议、或混入依赖了第三方 Sass 包时，加载失败静默发生，根本不会报错，只输出空 CSS。
-
compileString()不自动解析@use "mylib"，除非你在loadPaths里明确告诉它去哪找mylib；相对路径容易错，建议一律用path.resolve() - 混入中用了
@debug或@warn？它们的内容会被拼进最终 CSS 字符串，导致比对失败——CI 环境下尤其难发现 - 项目全局启用了
px-to-rem转换？那你测试@mixin btn-size($px)时，实际输出可能是padding: 0.75rem，而不是你 expect 的12px - 别在测试里用
* { list-style: none }这类通配重置——它会污染整个编译上下文，让后续所有测试的 CSS 输出都带上无关规则
