import { describe, it, expect } from 'vitest'
import { resolveGapPx, numberFromPx } from './visual-verify/lib/drift-compare-core'

// INFRA-F106（2026-08-28）。被测的是「量具怎么读 gap」，不是组件。
// 缘起：Slider 的 rootGap 报 `expected 8 / actual null`，被登记成 code 债并进了豁免表；
// 实测根因是 `getComputedStyle(el).gap` 这个**简写**在只声明 column-gap 时算出 "normal 8px"。
describe('resolveGapPx — gap 简写不可解析时回落到 column-gap 分量', () => {
  it('简写可解析时直接用它（既有行为不变）', () => {
    expect(resolveGapPx({ gap: '8px', columnGap: '8px' })).toBe(8)
    expect(resolveGapPx({ gap: '0px', columnGap: '0px' })).toBe(0)
    expect(resolveGapPx({ gap: '12.5px', columnGap: '12.5px' })).toBe(12.5)
  })

  it('两轴不同时，简写形如 "4px 8px" ⇒ 取简写的第一段（既有行为，row 在前）', () => {
    // ⚠️ 如实登记：本仓 expected.rootGap 来自 Figma 的单轴 itemSpacing，
    // 双轴不等的元素今天全仓为零。此用例只钉住「不因本次改动而变」。
    expect(resolveGapPx({ gap: '4px 8px', columnGap: '8px' })).toBe(4)
  })

  it('🔑 只声明 column-gap ⇒ 简写是 "normal 8px" ⇒ 回落取 8（本次修的那一条）', () => {
    expect(resolveGapPx({ gap: 'normal 8px', columnGap: '8px' })).toBe(8)
  })

  it('阴性对照：同样的简写、但拿不到 columnGap ⇒ 仍是 NaN', () => {
    // 证明上一条的 8 确实来自 columnGap 分量，不是判据碰巧把 "normal 8px" 解析对了。
    expect(Number.isNaN(resolveGapPx({ gap: 'normal 8px' }))).toBe(true)
  })

  it('阴性对照：修法没有把 numberFromPx 本身改宽（React 侧共用它）', () => {
    // 若有人日后把回落逻辑塞进 numberFromPx，这条会红 —— 那会静默改变 React 侧读数。
    expect(Number.isNaN(numberFromPx('normal 8px'))).toBe(true)
  })

  it('两轴都缺省（gap: "normal"）仍是 0，不被回落改写', () => {
    expect(resolveGapPx({ gap: 'normal', columnGap: 'normal' })).toBe(0)
  })
})