첫 테스트 한 개

무엇을 테스트할지 정하기에서 적은 크리티컬 흐름 한 줄이, 이 단계에서 실제로 돌아가는 테스트 한 개로 바뀝니다. 코드는 AI가 씁니다. 본인이 할 일은 결정 몇 개에 답하고, 결과를 한 번 눈으로 확인하는 것입니다.

이 단계는 두 스킬로 나뉩니다. /4-design-suite가 “어떻게 테스트할지”를 정하고, /5-implement-suite가 그 결정대로 테스트를 짭니다.

1) /4-design-suite — 어떻게 테스트할지 정하기

/4-design-suite가 호출되면 몇 가지를 묻습니다. 트랙은 앞 단계에서 이미 정했으니 여기서는 그 위에서 도구와 환경을 확정합니다.

• 트랙별 도구: web이면 Playwright, electron이면 Playwright _electron, mobile이면 Maestro가 기본입니다. 특별한 사정이 없으면 기본을 따르면 됩니다. 이건 되돌리기 비싼 결정이라 experienced 호흡이어도 한 번에 하나씩 묻습니다.
• 인증과 환경: 테스트가 로그인을 어떻게 처리할지, 어느 환경에 붙을지.
• CI: 나중에 GitHub에서 자동으로 돌릴지. 지금 당장 안 정해도 됩니다. “나중에”로 두고 넘어가도 됩니다.

도구처럼 한번 정하면 바꾸기 번거로운 결정은 AI가 그 근거를 ADR이라는 짧은 기록으로 남깁니다. 비개발자 입장에서는 그게 어디 적히는지만 알아 두면 됩니다. docs/adr/ 폴더입니다. 나중에 “왜 이 도구를 골랐더라”가 궁금해지면 거기를 보면 됩니다.

답을 마치면 결정이 e2e-suite-config.json에 박히고, docs/design/e2e-spec.md의 뒷부분에도 채워집니다.

2) 로그인은 한 번만 합니다

여기서 비개발자가 가장 헷갈리는 자리를 미리 짚어 둡니다. 테스트마다 매번 로그인 화면을 거치지 않습니다.

크리티컬 흐름이 다섯 개라고 매번 아이디와 비밀번호를 넣어 로그인하면, 테스트가 느려지고 로그인 화면이 조금만 바뀌어도 다섯 개가 한꺼번에 깨집니다. 그래서 이 base는 로그인을 한 번만 하고 그 상태를 저장해서 다른 테스트들이 재사용하게 만듭니다.

트랙마다 방식이 조금 다릅니다.

• web: 한 번 로그인한 다음 그 세션 상태(storageState)를 파일로 저장해 두고, 다른 테스트들이 그 파일을 불러와 이미 로그인된 상태에서 시작합니다.
• mobile: 로그인 흐름을 따로 한 번 돌려 두고 다른 흐름이 그 위에서 이어집니다.
• electron: 세션을 주입해서 로그인 상태로 띄웁니다.

이 자리는 AI가 알아서 배선합니다. 본인은 “매번 로그인 안 하고 한 번만 하는구나” 정도만 알면 됩니다.

3) /5-implement-suite — 테스트 짜기

설계가 끝나면 /5-implement-suite가 그 결정대로 테스트를 구현합니다. 가장 먼저 자동화하기로 한 흐름(smoke 후보) 한 개부터 시작하는 게 좋습니다.

이때 AI는 흐름 한 줄을 테스트 한 개로 옮깁니다. 예를 들어 “로그인한 사용자가 설정에서 프로필 이름을 바꾸면 저장된다”는 흐름이라면, AI가 설정 페이지를 열고, 이름 칸을 찾아 새 값을 넣고, 저장을 누르고, 저장됐는지 확인하는 테스트를 짭니다.

화면에는 어떤 파일이 만들어지는지 진행 줄이 흘러갑니다. web 트랙이면 tests/web/specs/ 아래에 .spec.ts 파일이, mobile이면 tests/mobile/flows/ 아래에 .yml 파일이 생깁니다. 파일 이름이 안 보여도 괜찮습니다. 다음 단계에서 실제로 돌려 보면 잘 짜였는지 바로 드러납니다.

4) 정상 모습과 멈추는 자리

정상 모습: AI가 테스트 파일을 만들고 “구현 완료, 이제 /run-suite로 돌려 볼까요?” 같은 안내로 넘어갑니다.

멈추는 자리: AI가 “설정 페이지의 이름 입력 칸을 어떻게 찾나요?” 같은 걸 되물을 수 있습니다. 본인 앱의 화면을 AI가 직접 본 적이 없어서 어느 버튼, 어느 입력 칸인지 헷갈리는 자리입니다. 이럴 때는 그 화면에 보이는 라벨(예: “이름”, “저장”)을 그대로 알려 주면 됩니다. AI는 보이는 글자나 버튼 역할로 요소를 찾는 걸 선호합니다.

한 번에 너무 많이 시키지 않기: 흐름 다섯 개를 한꺼번에 짜라고 하기보다 한 개를 먼저 끝까지(짜고 → 돌리고 → 통과) 가는 편이 낫습니다. 첫 한 개가 돌면 나머지는 같은 패턴이라 빨라집니다.

다음

첫 테스트가 만들어졌다면 실제로 돌려서 통과하는지 봐야 합니다. 실행하고 보고서 읽기로 갑니다. 도중에 AI가 같은 자리에서 두 번 막혔다면 AI가 막혔을 때를 봅니다.