자동 테스트 생성
단위 테스트, 통합 테스트, E2E 테스트 — 코드를 OpenClaw에 던지면, 테스트 케이스는 자동으로 생성
테스트 쓰는 것도 힘드네…
테스트는 항상 맨 뒤에
기능을 출시하느라 바빠서, 테스트는 항상 "다음 버전에 보충하자"는 식이다. 그러다 출시하고 터지더라. 경계 케이스를 전혀 못 했다는 걸 알게 된다.
목(mock) 데이터를 쓰다 보면 진짜 절망한다. 하나의 API가 세 개 서비스를 의존하는데, 목 데이터만 짜는 데 30분이 걸린다. 비즈니스 코드보다도 많다.
커버리지 리포트를 보니 30%다. 상사가 물으니까 입으로만 "핵심 로직은 다 테스트했어"라고 말한다. 사실은 happy path도 다 못 했다.
OpenClaw가 테스트를 어떻게 해결해주는가
너의 코드를 읽고, 믿을만한 테스트를 생성한다
OpenClaw는 그냥 대충 몇 개 테스트 케이스를 짜서 대충하지 않는다. 함수 시그니처, 분기 로직, 예외 처리 경로를 분석해서, 경계 조건과 예외 시나리오를 자동으로 찾아낸다.
함수가 null 검사를 한다? null 입력 테스트를 생성한다. 루프가 있다? 빈 배열, 한 개 요소, 대량 데이터 테스트를 한다. try-catch가 있다? 예외를 유발하는 입력을 만든다.
게다가 너의 프로젝트가 쓰는 테스트 프레임워크를 이해한다 — Jest, Pytest, JUnit, Vitest. 생성된 코드가 그냥 실행 가능하니까, 손으로 형식을 안 고쳐도 된다.
그냥 쓸 수 있는 테스트 프롬프트
3가지 프롬프트로 단위 테스트, E2E 테스트, 부하 테스트를 다룬다. 필요에 따라 고르면 된다.
단위 테스트 완전 커버리지
황금 지시문
이 모듈의 모든 내보낸 함수와 클래스 메소드를 분석해.
각 함수마다 완전한 단위 테스트를 생성하게. 요구사항:
1. 커버리지 목표 90% 이상 (문장 커버리지 + 분기 커버리지)
2. 각 함수마다 최소 테스트: 정상 입력, 경계값, 예외 입력
3. 외부 의존성은 mock을 쓰고, 진짜 데이터베이스나 네트워크에 의존하지 마
4. 테스트 명은 명확하게, "should xxx when xxx" 형식으로
5. 필요한 setup/teardown 추가해
이 프로젝트의 기존 테스트 프레임워크와 단정(assertion) 라이브러리를 써서, 스타일 일관성 유지해.
이게 가장 자주 쓰인다. 파일 하나를 던지면, 몇 초 안에 테스트가 나온다. 커버리지 90%는 말 그대로다. 너가 생각 못 한 경계 케이스도 다 추가된다.
E2E 로그인 흐름 테스트 (Playwright)
고급 팁
Playwright로 다음 로그인 흐름을 위한 E2E 테스트를 작성해:
테스트 시나리오:
1. 정상 로그인: 올바른 유저명과 비밀번호 입력, 홈페이지로 이동하는지 확인
2. 틀린 비밀번호: 잘못된 비밀번호 입력, 에러 메시지가 표시되는지 확인
3. 빈 폼 제출: 아무것도 입력 안 하고 제출 누르기, 폼 검증이 되는지 확인
4. 나를 기억해 주기: "나를 기억해" 체크, 닫았다가 다시 열어서 로그인 상태 확인
5. 로그아웃: 로그인 후 로그아웃 누르기, 로그인 페이지로 돌아오는지 확인
요구사항:
- Page Object Model 패턴으로 코드 구성
- 합리적인 대기 전략 추가, sleep 쓰지 마
- 실패 시나리오는 스크린샷 찍어서 디버깅에 활용
Playwright의 E2E 테스트는 작성하기 번거로운데, 특히 대기 전략과 선택자가 그렇다. AI에게 초판을 짜게 하고, 너가 실제 페이지에 맞게 조정하면, 효율이 배로 올라간다.
API 부하 테스트 스크립트
고급 팁
다음 API 인터페이스를 위한 부하 테스트 스크립트를 생성하게 (k6 또는 Artillery 사용):
테스트 설정:
1. 점진적 가압: 10개 동시성부터 시작해서, 30초마다 10씩 증가, 최대 200 동시성
2. 지속 시간: 총 5분
3. 요청 분포: 읽기 70%, 쓰기 20%, 업데이트 10%
4. 기록 지표: P50/P95/P99 레이턴시, 에러율, 처리량
생성 결과 분석 스크립트를 만들어서, 성능 병목 보고서를 출력해.
P99가 500ms를 넘거나 에러율이 1%를 넘으면, 최적화 필요로 표시해.
부하 테스트 스크립트를 처음부터 짜면 반나절이 든다. 이 프롬프트가 바로 프로덕션급 설정을 준다. 결과 분석 스크립트도 포함되어 있다.
테스트 생성: OpenClaw vs Copilot
둘 다 테스트를 생성할 수 있지만, 생성 품질 차이가 꽤 크다.
OpenClaw
- 완전한 함수 로직과 분기 경로를 분석, 경계 케이스 커버리지 완벽함
- 파일 간 의존성을 이해, 목 생성이 정확함
- 커버리지 목표를 지정할 수 있고, 미달하면 케이스를 보충함
- E2E, 부하 테스트 같은 복잡한 시나리오의 완전한 스크립트를 생성
VS
Copilot
- 현재 파일만 생성해서, 파일 간 의존성을 놓치기 쉬움
- 주로 happy path 테스트만 생성해서, 경계 커버리지가 부족함
- 목을 손으로 고쳐야 할 때가 많음
- 복잡한 테스트 시나리오 (E2E, 부하 테스트) 지원이 제한적
실제 상황: 긴급 출시 전에 테스트 보충
금요일 오후 4시. 상사가 오늘밤 출시해야 한다고 말한다
새 기능을 2주 동안 개발했는데, 테스트 커버리지가 20%밖에 없다. QA는 최소 70%까진 가야 출시 허가할 수 있단다. 너한테 3시간이 남았다.
OpenClaw
핵심 모듈을 OpenClaw에 던져서, 프롬프트 하나로 완전한 테스트 스위트를 생성한다. 자동으로 어떤 분기가 미커버이고, 경계 테스트와 예외 처리를 보충할지 분석한다. 3시간 안에 80% 커버리지를 확보하고, QA가 맘 놓고 사인한다.
손 테스트 작성
미친 듯이 테스트를 짜기 시작한다. 그런데 의존성을 정리하는 데만 1시간이 걸린다. 목을 세 번이나 틀려서 테스트가 실행이 안 된다. 결국 커버리지가 겨우 45%라 QA가 통과 안 시켜주고, 밤새 작업한다.
몇 가지 실용 팁
테스트를 생성한 후 한 번 돌려서, 통과하는지 확인해. 실패한 케이스가 있으면, 에러 메시지를 OpenClaw에 붙여서, 수정하도록 해.
한 번에 모든 테스트를 생성하지 말고, 모듈별로 나눠서 생성해. 매번 한 파일에 집중하면, 테스트 품질이 더 높아진다.
테스트 생성은 Claude Opus 4.6이 가장 잘하는데, 특히 복잡한 비즈니스 로직이 있을 때 그렇다. 간단한 유틸리티 함수 테스트는 DeepSeek V3.2면 충분해서, 비용을 절약할 수 있다.