테스트 DB 사용하려다보니 self hosted git action runner를 사용하게 됨. 라즈베리파이 특성상 파이프라인 실행이 깃허브 서버의 러너 대비 너무 오래 걸려서 테스트 과정의 초기 단위테스트, 린트, 통합테스트 단계를 클로드 코드에게로 위임하고 최종 e2e 테스트를 실행하는 playwright의 검증 단계만 남기기로 결정. 결과적으로 훨씬 속도가 빨라짐.

my-blog: CI 파이프라인 간소화 및 테스트 추가

코드 변경 사항 첨언

backend/scripts 디렉토리에 데이터베이스 백업 및 복원 스크립트를 추가하여 테스트 실행 전후의 데이터베이스 상태를 관리하도록 수정했습니다.
또한, frontend/tests/e2e/blog.spec.js 파일에서 Playwright 테스트 코드의 일부가 개선되어 전반적인 테스트 커버리지를 향상시키고, package-lock.json에서 Tailwind CSS 관련 패키지 버전이 업데이트되었습니다.

배경 및 목적

기존 CI 파이프라인은 린트와 단위 테스트, 인프라 설정 검사까지 포함하는 형태였는데 라즈베리 특성상 시간이 너무 오래걸렸습니다. 마음에 들지 않아, 정말 필요한 테스트는 무엇인가? 라는 고민으로 이어졌고 결국 실제 사용자 경험에 더 밀접한 E2E(End-to-End) 테스트가 가장 중요하다 생각했습니다. 이전 단계들은 클로드 코드의 능력에 맡기고 npm ci 및 최종 웹 페이지 접근 및 기능 수행 테스트만 ci.yml을 이용하도록 변경했습니다. 그리고 테스트가 끝나면 테스트 DB의 상태가 테스트 전 상태로 복원되도록 하였습니다.

구현 내용

이번 변경은 다음과 같은 주요 부분으로 구성됩니다.

CI 파이프라인 간소화 (`.github/workflows/ci.yml`)

기존: 린트 및 단위 테스트 단계를 포함한 여러 단계로 구성되었습니다.
변경: 린트 및 단위 테스트 단계를 제거했습니다. 대신, Playwright를 이용한 웹 페이지 테스트 단계를 유지하되, 테스트 실행 전후에 데이터베이스 백업 및 복원 스크립트를 실행하도록 수정했습니다.
파일 변경: .github/workflows/ci.yml
추가 라인: 35
삭제 라인: 40
핵심 변경:
- web-page-tests 잡에 backend/scripts/backup-test-db.sh 및 backend/scripts/restore-test-db.sh 스크립트 실행 로직이 추가되었습니다.
- Install dependencies 단계에서 unattended-upgrades 서비스 중지 관련 내용이 추가되었습니다.
- Install Playwright browsers 단계가 간소화되었습니다.
- 서버 준비 확인 로직에서 curl 명령의 출력을 /dev/null로 리다이렉션하도록 변경하여 불필요한 출력을 제거했습니다.
- check-infra 잡이 완전히 제거되었습니다.

테스트 데이터베이스 백업 및 복원 스크립트

신규 추가: 테스트 실행 전에 posts 및 projects 테이블의 데이터를 백업하고, 테스트 실행 후에 해당 데이터를 복원하는 스크립트가 추가되었습니다. 이를 통해 매번 테스트 실행 시 일관된 데이터 상태를 유지할 수 있습니다.
파일 추가:
- backend/scripts/backup-test-db.sh
- backend/scripts/restore-test-db.sh
추가 라인: backup-test-db.sh 43 라인, restore-test-db.sh 46 라인
핵심 변경:
- backup-test-db.sh: pg_dump를 사용하여 posts와 projects 테이블의 데이터만 백업 파일(posts.sql, projects.sql)로 저장합니다. 백업 디렉토리는 /tmp/blog-test-backups입니다.
- restore-test-db.sh: 백업된 posts.sql과 projects.sql 파일을 이용하여 해당 테이블의 데이터를 삭제하고 새로 복원합니다.

Playwright E2E 테스트 개선 (`frontend/tests/e2e/blog.spec.js`)

변경: 블로그 관련 E2E 테스트 코드가 대폭 수정 및 확장되었습니다. 홈페이지, 포스트 목록, 상세 페이지, 프로젝트 페이지 등에 대한 테스트가 추가되었으며, 포스트 및 프로젝트 생성, 수정, 삭제(CRUD) 기능에 대한 테스트도 포함되었습니다.
파일 변경: frontend/tests/e2e/blog.spec.js
추가 라인: 352
삭제 라인: 19
핵심 변경:
- 홈페이지 로드 및 에러 메시지 확인, DB 에러 시 처리, 최신 글/프로젝트 섹션 존재 여부 테스트가 추가되었습니다.
- 포스트 목록 페이지 로드 및 글 형식 표시, 포스트 상세 페이지 로드, 글 수정(제목, 요약, 본문, 태그) 및 삭제 테스트가 추가되었습니다.
- 프로젝트 목록 페이지 로드, 프로젝트 카드 표시, 프로젝트 상세 페이지 로드, 프로젝트 수정 및 삭제 테스트가 추가되었습니다.
- 소개 페이지(/about) 접속 및 내용 표시 테스트가 추가되었습니다.

의존성 업데이트 (`frontend/package-lock.json`)

변경: Tailwind CSS 관련 패키지들의 버전이 업데이트되었습니다.
파일 변경: frontend/package-lock.json
추가 라인: 135
삭제 라인: 189
핵심 변경:
- @tailwindcss/vite, @tailwindcss/oxide, tailwindcss 등의 패키지 버전이 4.1.18에서 4.2.1로 업데이트되었습니다.
- lightningcss 관련 패키지들도 1.30.2에서 1.31.1로 업데이트되었습니다.
- Node.js 엔진 요구 사항이 일부 패키지에서 >=10에서 >=20으로 변경되었습니다.

기술적 의사결정

이 커밋에서는 여러 기술적인 의사결정이 이루어졌습니다.

CI 파이프라인 간소화

기술 선택: 린트 및 단위 테스트, 인프라 검사 제거, E2E 테스트 강화.
이유: 프로젝트의 핵심 가치인 사용자 경험 테스트에 집중하고, CI 실행 시간을 단축하기 위함입니다. 린트와 단위 테스트는 개발 환경에서 충분히 검증 가능하며, CI는 배포 가능한 상태임을 보장하는 데 초점을 맞추는 것이 효율적이라고 판단했습니다.

테스트 데이터베이스 관리

기술 선택: pg_dump 및 psql을 이용한 데이터베이스 백업/복원 스크립트 구현.
이유: E2E 테스트는 항상 일관된 데이터 상태에서 실행되어야 신뢰성을 확보할 수 있습니다. 스크립트를 통해 명시적으로 백업 및 복원을 수행이 필요하다고 생각했습니다.
대안: Mock 데이터를 생성하거나, 테스트 전용 인메모리 데이터베이스를 사용하는 방안도 있었으나, 실제 운영 데이터베이스와 유사한 환경에서 테스트하기 위해 기존 PostgreSQL 운영 데이터베이스의 레플리카로부터 테스트 DB를 준비하는 방식을 선택했습니다.
장단점:
- 장점: 테스트 환경의 데이터 일관성 확보, 재현 가능한 테스트 환경 구축.
- 단점: 백업 및 복원 과정 자체에 시간이 소요될 수 있으며, 대규모 데이터베이스의 경우 성능 이슈가 발생할 수 있습니다.

배운 점 및 개선점

이번 작업을 통해 CI 파이프라인의 효율성과 테스트 데이터 관리의 중요성을 되새겼습니다.

배운 점

CI 파이프라인은 프로젝트의 성숙도와 우선순위에 따라 계속해서 최적화되어야 한다는 점을 배웠습니다. 모든 테스트를 CI에 포함시키는 것보다, 각 테스트 단계의 목적과 비용 대비 효과를 고려하는 것이 중요합니다.
E2E 테스트에서 데이터 일관성은 중요하며, 이를 보장하기 위한 전략이 필요하다는 것을 알게 되었습니다. 스크립트를 통한 백업/복원 방식은 이러한 요구사항을 충족하는 효과적인 방법입니다.
Playwright를 이용한 E2E 테스트 작성 시, UI 요소 선택자, 비동기 처리, 동시성 문제 등을 고려해야 한다는 것을 경험했습니다.

개선점 및 다음 단계 계획

개선점:
- 현재 백업/복원 스크립트는 posts와 projects 테이블에만 국한되어 있습니다. 향후 다른 테이블에도 테스트 데이터가 필요해진다면 스크립트를 확장해야 할 수 있습니다.