# rqlite가 테스트하는 방법 > Clean Markdown view of GeekNews topic #18772. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=18772](https://news.hada.io/topic?id=18772) - GeekNews Markdown: [https://news.hada.io/topic/18772.md](https://news.hada.io/topic/18772.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-01-17T10:19:58+09:00 - Updated: 2025-01-17T10:19:58+09:00 - Original source: [philipotoole.com](https://philipotoole.com/how-is-rqlite-tested/) - Points: 5 - Comments: 1 ## Summary rqlite는 가벼운 오픈 소스 분산 관계형 데이터베이스로, 신뢰성과 품질을 우선시하며 테스트 피라미드를 준수하여 단위 테스트, 시스템 수준 테스트, 엔드 투 엔드 테스트를 통해 품질을 유지합니다. 단위 테스트는 약 27,000줄로 구성되어 있으며, 시스템 수준 테스트는 Raft 컨센서스 모듈과 SQLite의 상호작용을 검증하고, 엔드 투 엔드 테스트는 주요 기능을 검증하는 스모크 테스트 역할을 합니다. 성능 테스트를 통해 최대 INSERT 속도와 동시 쿼리 처리 등의 메트릭을 평가하며, 테스트의 단순성을 유지하고 효율성을 중시하여 빠른 반복 개발을 가능하게 합니다. ## Topic Body - rqlite는 가벼운 오픈 소스 분산 관계형 데이터베이스로, Go로 작성되었으며, SQLite와 Raft를 기반으로 개발됨 - 2014년부터 개발이 시작되었으며, 신뢰성과 품질을 우선시하며, 10년 이상의 개발과 배포 후에도 프로덕션 환경에서 10건 미만의 패닉 사례만 보고됨 - 분산 시스템 테스트는 여러 레이어에서 세심한 고려가 필요하며, 단순함 속에서 품질을 유지하는 철학을 따름 ### 테스트 피라미드: 효과적인 접근법 - rqlite 테스트는 "테스트 피라미드"를 준수함 - 테스트 피라미드: 단위 테스트를 기반으로, 통합 테스트와 최소한의 엔드 투 엔드 테스트(E2E)를 포함하는 구조 - 효율적이고 디버깅이 용이하며, 목표 지향적인 테스트 스위트를 제공 ### 단위 테스트: 품질의 핵심 - 단위 테스트는 독립적인 컴포넌트를 테스트하며, 속도와 정확성의 균형을 제공함 - SQLite와 "shared nothing" 아키텍처를 기반으로 대부분의 기능이 단위 테스트로 커버 가능 - 전체 rqlite 코드(약 **75,000줄**) 중 단위 테스트는 약 **27,000줄**로 구성됨 - 테스트는 몇 분 안에 완료되며, 개발 중 빈번한 테스트가 가능함 ### 시스템 수준 테스트: 컨센서스 검증 - 시스템 수준 테스트는 Raft 컨센서스 모듈과 SQLite의 상호작용을 검증함 - 주요 테스트 항목: - SQLite 명령문의 노드 간 복제 - 다양한 일관성 수준에서의 읽기 작업 - 클러스터 장애 복구 및 리더 선출 검증 - 약 **7000줄**의 테스트 코드로 단일 노드 및 다중 노드 구성의 상호작용을 포괄적으로 커버 ### 엔드 투 엔드 테스트: 최소한의 레이어 - 엔드 투 엔드 테스트는 시스템 시작, 클러스터링, 기본 동작을 확인하는 **스모크 테스트** 역할을 함 - Python으로 작성되었으며 실제 rqlite 클러스터를 실행하여 주요 기능을 검증함 - 예: AWS S3로의 백업 검증 - 테스트 코드 약 **5000줄**로 제한적인 접근법을 사용하여 디버깅 비용을 최소화 ### 성능 테스트: 한계를 시험 - 성능 테스트는 다음과 같은 메트릭을 평가: - 최대 INSERT 속도 - 동시 쿼리 처리 - 메모리, CPU, 디스크 사용량 비교 - 2GB 이상의 SQLite 데이터베이스 테스트를 포함하여 메모리 관리와 디스크 쓰기 병목현상을 분석 - 성능 문제를 발견하고 최적화를 통해 안정성을 보장 ### 배운 교훈 - **초기부터 테스트 시작** - 단위 테스트는 시스템 신뢰를 구축하는 가장 효과적인 방법 - 개발 중 단위 테스트 작성을 미루지 말아야 하며, 버그를 통합 테스트나 E2E 테스트보다 빠르게 발견 가능 - **테스트 코드를 단순하게 유지** - 테스트 스위트는 복잡한 리팩토링이나 **DRY(Don't Repeat Yourself)** 원칙을 고집하는 장소가 아님 - 이해하기 쉬운 코드를 작성하는 것이 중요하며, 추가적인 보일러플레이트 코드도 허용해야 함 - **테스트를 검증** - 테스트 작성 시, 일시적으로 예상 결과를 반대로 설정하여 테스트를 다시 실행 - 제대로 작성된 테스트는 이 경우 실패해야 하며, 이를 통해 테스트 코드의 오류를 사전에 방지 가능 - **테스트 실패를 무시하지 말기** - 이해하기 어렵거나 드문 테스트 실패라도 소프트웨어에 대해 중요한 정보를 제공 - 디버깅이 어려운 실패 사례는 종종 코드의 치명적인 결함을 발견할 기회가 될 수 있음 - **결정론 최대화** - 시스템의 자동 프로세스를 수동으로 실행할 수 있는 메커니즘을 구축 - 예: Raft 스냅샷 기능은 일반적으로 반자동으로 실행되지만, 테스트 중 명시적으로 트리거 가능하도록 설계 - **신중한 태도(Be Deliberate)** - 상위 수준의 통합 테스트나 E2E 테스트는 필요성이 명확히 입증될 때만 추가 - 과도한 테스트는 개발 및 디버깅 속도를 저하시킬 수 있음 - **적용 및 반복** - 성능 테스트에서 **fsync 호출**이 주요 병목현상으로 확인되었으며, Raft 로그 엔트리를 디스크에 쓰기 전에 압축하여 디스크 사용 최적화 - **효율성 중시** - 몇 분 안에 실행 가능한 테스트 스위트를 유지하여 빠른 반복 개발 가능 - 이는 오픈 소스 프로젝트의 유지와 활성화에 필수적인 장점 ### 품질 우선 - 테스트 피라미드를 준수하며, 각 테스트 레이어가 명확한 목적을 갖도록 설계 - 분산 시스템의 복잡성이 증가함에 따라 테스트의 단순성을 유지하는 것이 핵심 - 신뢰할 수 있고 운영이 용이한 데이터베이스를 구축하는 것이 목표 ## Comments ### Comment 33541 - Author: neo - Created: 2025-01-17T10:19:58+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=42703282) - 첫 번째 테스트는 가장 어렵지만 추가할 가치가 있음. 이후 테스트는 더 쉬워짐 - 매개변수화된 테스트는 반복 코드를 줄이고 다양한 테스트를 가능하게 함 - 제약 조건의 철저한 검증이 가능할 때 유용함 - Prop 테스트는 일관성과 불변성을 검증하는 데 도움을 줌 - 변이 테스트를 사용하여 실제로 테스트하고 있는지를 확인하는 것이 중요함 - 프로젝트에 대한 헌신이 인상적임 - 테스트 피라미드는 이해가 되지만, 모든 레벨이 없는 경우가 많아 이를 빠르게 개선해야 하는 상황임 - 여러 팀과 협력하는 경우 e2e 레이어를 채우는 것이 아무도 맡지 않는 일이 됨 - Auth0 같은 인증 메커니즘을 사용하는 경우 테스트가 어려움 - e2e 테스트가 없으면 시스템이 쉽게 깨질 수 있음 - 자동화된 e2e 테스트는 문제를 쉽게 식별하고 롤백할 수 있게 해줌 - FAQ에 복사 붙여넣기 오류가 있는 것 같음 - Jepsen 보고서를 기대하고 있음 - 비디오 형식으로도 즐겼음 - 성능 테스트 설정이 부러움 - rqlite를 사용해봤고, 단순함을 잘 전달함 - 결정론적 시뮬레이션 테스트에 대한 의견을 묻고 있음 - rqlite를 실제 환경에서 사용하는지 궁금해함 - rqlite는 독창적이고 천재적인 프로젝트임