프로젝트 폴더 열기
FlowLatch를 시작하고 테스트 폴더를 작업 폴더로 선택하세요. Ask first를 선택하면 변경을 일으키는 모든 작업이 당신의 확인을 기다립니다. 모델을 아직 연결하지 않았다면 연결하고, Test 버튼을 사용해 엔드포인트를 확인하세요.
워크플로우
자동 웹 테스트: 열고, 실행하고, 읽고, 수정하는 흐름
03
스테이징 앱의 체크아웃 흐름을 확인하세요
가게의 스테이징 복사본, 테스트 계정, 테스트 폴더가 있고, 오늘의 변경 후 로그인, 장바구니 추가, 결제가 여전히 작동하는지 확인하고 싶다고 가정해 보세요. 이는 가장 작은 규모의 자동 웹 테스트입니다: 하나의 흐름, 하나의 테스트 명령, 읽을 수 있는 하나의 결과. FlowLatch는 폴더를 열고 Shell을 통해 명령을 실행한 후 카드에 실제 종료 코드를 표시합니다. 흐름이 실패하면 라인 번호를 가리키고 diff 형태로 수정안을 제안하며, 최종 승인은 당신의 몫입니다. 아래 단계는 폴더에서 결과까지 4가지 동작을 수행합니다. 빌드하거나 테스트 권한이 있는 앱에서만 작업하세요. 테스트 계정과 가짜 데이터를 사용하고, 결제 단계에서는 실제 카드가 아닌 자체 결제 설정의 테스트 모드를 사용하세요. 이메일 확인은 테스트용으로 설정된 받은 편지함으로 이동합니다.
테스트 파일 나열하기
테스트 구조를 물어보세요. list_dir와 glob은 파일을 표시하고, read_file은 체크아웃 흐름을 열어주어 실행이나 변경 전에 당신과 에이전트가 같은 텍스트에서 시작할 수 있습니다. 각 작업은 결과와 함께 채팅 카드에 표시됩니다.
테스트 명령 실행하기
프로젝트가 사용하는 테스트 명령을 에이전트에게 알려주세요. Shell은 Windows 또는 WSL에서 명령을 실행하며, 카드는 전체 출력과 요약이 아닌 실제 종료 코드를 보여줍니다. 모든 라인을 보고 싶으면 카드를 확장하고, grep을 사용해 실패한 단계로 이동하세요.
결과와 수정안 읽기
실패 시 출력이 무엇을 의미하는지 물어보세요. 에이전트는 diff 형태로 수정을 제안하며, 당신이 승인하기 전까지 아무것도 쓰여지지 않습니다. 잘못 보이는 것은 거절하고, 명령을 다시 실행해 새로운 종료 코드를 확인하세요. 흐름이 통과하거나 앱에서 무엇을 수정해야 하는지 알 때까지 반복하세요.
복사해서 사용할 수 있는 테스트 흐름 개요
내 스테이징 복사본에서 체크아웃 흐름을 실행하고 실패한 부분을 알려줘.
- list_dir
tests/나열됨 - read_file
tests/checkout-flow-test.txt로드됨 - Shell
your test commandexit 0 - grep
FAIL reports/일치 항목 없음
다음 단계를 진행하기 전 사용자의 승인을 기다리는 중거부수락
checkout-flow-test.txt
# checkout flow for the staging copy of my shop
# uses only the test account and fake data
step 1: open the sign-in page
step 2: sign in with the test account
step 3: search for the sample product
step 4: add the sample product to the cart
step 5: open the cart and start checkout
step 6: pay in the test mode of my payment set-up
expect 1: the order confirmation page is shown
expect 2: the order list shows the new test order
expect 3: the test inbox received the confirmation
# when a step fails, save a screenshot and the page text이 개요는 평문이며 테스트 파일 옆의 저장소에 있습니다. 자체 테스트 프레임워크는 각 단계를 코드로 변환하고, FlowLatch는 해당 코드를 작성하고 실행하며 결과를 세 가지 expect 라인과 비교할 때 이 파일을 명세로 사용합니다. 제품명과 페이지를 자신의 스테이징 앱에 맞게 변경하세요.
자동 브라우저 테스트를 위한 워크스루
기존 테스트 찾기 및 읽기
테스트가 어디에 있는지 물어보는 것으로 시작하세요. list_dir은 폴더를 보여주고, glob은 체크아웃 테스트와 같은 패턴에 일치하는 모든 파일을 나열하며, read_file은 관심 있는 파일을 열어 현재 흐름이 어떻게 구축되어 있는지 볼 수 있게 합니다. grep은 사용된 선택자와 대기 조건을 검색합니다. 이 모든 작업은 읽기만 하므로, 계획을 세우고 아무것도 실행하지 않는 Plan only 모드에서 첫 단계로 적합합니다. 계획은 재시작 후에도 유지되므로 내일 다시 돌아올 수 있습니다. 실제 실행을 준비했다면 Ask first로 전환하고 계획을 다시 확인하세요. 이미 커버된 흐름을 적어 두어 테스트가 누락된 부분을 파악하세요.
수트 실행 및 종료 코드 읽기
런타임 업그레이드 후 e2e 수트 실패는 종종 앱보다 환경에서 비롯되므로, 테스트를 건드리기 전에 첫 오류를 읽어보세요. Shell은 테스트 명령을 실행하며 카드는 전체 출력과 유일한 정직한 통과/실패 기준인 실제 종료 코드를 유지합니다. grep은 긴 로그에서 실패한 단계를 추출할 수 있습니다. 채팅에서 오류에 대한 평이한 설명을 요청하고, 출력과 비교한 후 테스트 파일 수정이 필요한지 결정하세요. 오류가 누락된 패키지나 변경된 설정을 가리킨다면 환경을 먼저 수정하고 같은 명령을 다시 실행하세요. 종종 수트는 수정 없이 통과하며, 카드의 종료 코드가 이를 증명합니다.
선택자 수정 및 재실행
ui 테스트 자동화에서 선택자 유지보수는 변경된 레이아웃으로 인해 연결된 선택자가 깨지기 때문에 가장 흔한 작업입니다. grep은 모든 파일에서 이전 선택자를 찾고, read_file은 주변 단계를 보여주며, edit_file은 대체할 안정적인 레이블이나 test id를 제안합니다. Ask first 모드에서는 에이전트가 멈추고 diff를 보여줍니다. 올바르게 보이는 라인을 승인한 후 Shell로 명령을 다시 실행하세요. 수정 후 녹색 종료 코드는 원하는 결과이며, diff는 다음 검토자를 위해 저장소 이력에 남습니다. 명령이 여전히 실패한다면 다른 변경을 요청하기 전에 새 출력을 읽어보세요. 잘못된 추측 위에 두 번째 수정을 하면 원인을 파악하기 어려워지기 때문입니다. 각 diff는 한 번에 읽을 수 있을 정도로 작게 유지하세요.
실패한 테스트 반복 실행하여 불안정성 확인
ui e2e 테스트가 실패할 때 실제 원인은 종종 앱이 아니라 고정된 대기 조건, 공유 테스트 데이터 또는 테스트 순서입니다. FlowLatch에게 같은 명령으로 실패한 테스트를 여러 번 실행하고 각 종료 코드를 보고하도록 요청하세요. 결과가 섞여 있으면 테스트가 불안정합니다. 프레임워크가 스크린샷을 저장했다면 ocr이 텍스트를 읽고, 실패한 실행의 페이지 텍스트는 두 번째 단서를 제공합니다. diff에서 대기 조건이나 데이터를 수정하고 검토한 후 테스트를 다시 실행하세요. 각 테스트에 고유한 데이터를 주고 리셋하며, 고정된 지연 대신 가시적인 조건을 기다리고 테스트 간 순서 의존성을 피하세요. 수정 후 한 번 더 실행을 반복하세요. 한 번의 통과로는 아무것도 증명되지 않습니다.
