Files

T

Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

2026-07-05 00:33:48 +09:00

3.3 KiB

Raw Blame History

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases

title

Snapshot Test

의도적으로 사용하면 강력하지만 무지성으로 쓰면 "test 가 그냥 현재 출력을 freeze" 함. 변경 → snapshot 갱신 → 의미 없는 통과. diff 검토 문화 가 핵심.

📖 핵심 개념

첫 실행: 출력 기록.
이후: 기록과 다르면 fail.
Inline snapshot: test 파일에 직접 (변화 즉시 보임).
File snapshot: 별도 .snap 파일.

💻 코드 패턴

React 컴포넌트 — 보수적 사용

import { render } from '@testing-library/react';

test('Header renders title', () => {
  const { container } = render(<Header title="Hello" />);
  expect(container).toMatchSnapshot();
});

⚠️ 큰 컴포넌트는 변화 잦음. inline + 핵심만 권장.

Inline snapshot — diff 즉시 visible

import { test, expect } from 'vitest';

test('format duration', () => {
  expect(formatDuration(95_000)).toMatchInlineSnapshot(`"1m 35s"`);
  // jest --ci 면 fail / 로컬 --updateSnapshot 으로 갱신
});

Serializer — 핵심만 비교

expect.addSnapshotSerializer({
  test: (val) => val instanceof Date,
  print: () => '"<Date>"',
});

// timestamp 같이 매번 다른 값은 mask
test('user object', () => {
  expect(makeUser()).toMatchSnapshot();
  // {"id": "<Date>", "createdAt": "<Date>", ...}
});

Property snapshot — 동적 값 마스킹

expect(user).toMatchSnapshot({
  id: expect.any(String),
  createdAt: expect.any(Date),
});

Golden file — 큰 출력

test('SQL builder generates expected query', async () => {
  const sql = build({ table: 'users', filters: { age: 18 } });
  await expect(sql).toMatchFileSnapshot('./golden/users.sql');
});

🤔 의사결정 기준

사용처	snapshot 적합
작은 안정적 컴포넌트	✅ 단 inline + 짧게
큰 페이지 컴포넌트	❌ — assertion 으로 행위 검증
빌더 / 직렬화 결과	✅ — golden file
API 응답 형식	❌ — schema 검증 (zod) 권장
CSS-in-JS 출력	❌ — 자주 바뀜
에러 메시지 텍스트	✅ inline

❌ 안티패턴

-u 무지성: CI 빨갛다고 자동 update. 의미 없는 통과.
거대 snapshot: diff 못 읽음. 작은 단위로 분할.
timestamp / random / uuid 안 마스킹: 매번 fail. property matcher.
snapshot only test: 비즈니스 행위 검증 0. assertion 결합.
inline 안 쓰고 매번 .snap 파일 열기: 흐름 깨짐. 작은 출력은 inline.
eslint-plugin-jest 의 no-large-snapshots 무시: 50줄 넘는 snapshot 은 검토 신호.
PR 에서 snapshot 변경 review 안 함: 사일런트 회귀.

🤖 LLM 활용 힌트

"snapshot 보단 명시적 assertion 우선. snapshot 은 builder/format/error 메시지 같은 안정 출력만" 명시.
동적 값은 property matcher 로 마스킹.

3.3 KiB Raw Blame History