직접 만든 사이트와 앱을 위한 UI 자동화

에이전트가 테스트를 위해 할 수 있는 일

• 파일read_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep, glob은 채팅의 작업 폴더 내에서 작동하며, 생성, 편집, 읽은 파일 수를 카운터로 보여줍니다.
• Shell로컬 Windows, WSL 또는 소유한 서버의 SSH를 통해 테스트 명령, 린터, 빌드를 실행하며 실제 종료 코드로 성공 여부를 판단합니다. 위험한 명령은 차단됩니다.
• 웹web_search는 페이지를 찾고 http_get은 공식 문서 페이지 하나를 읽어, 셀렉터나 대기 관련 질문을 프레임워크 자체 매뉴얼과 대조해 확인할 수 있게 합니다.
• 스크린샷 및 이미지ocr은 저장된 스크린샷(예: 실패한 실행의 오류 배너)의 텍스트를 읽고, gen_image는 필요할 때 실제 이미지 파일을 저장합니다.
• 오케스트레이션task는 독립적인 검사를 병렬 서브 에이전트 간에 분할하고, run_on_model은 하나의 어려운 단계를 더 큰 모델에 보내며, skill는 일반적인 수리 절차 같은 재사용 가능한 플레이북을 저장합니다.
• 승인 모드Auto-run은 즉시 실행하고, Ask first는 변경을 일으키는 작업 전에 일시 정지하고 diff를 보여주며, Plan only는 계획만 작성하고 아무것도 실행하지 않습니다. 계획은 재시작 후에도 유지됩니다.
• 크론일정대로 프롬프트를 실행합니다. 예를 들어 설정한 시간에 테스트 명령을 실행하고 종료 코드를 채팅에 보고하여, 밤새 깨진 흐름이 당신이 먼저 읽어야 할 내용이 됩니다.
• 모델표준 API 엔드포인트를 통해 클라우드 AI 공급자, PC에서 로컬로 실행되는 모델 또는 자체 엔드포인트 없이 바로 사용할 수 있는 내장 모델에 연결합니다. 테스트 버튼은 시작하기 전 엔드포인트를 확인합니다.

에이전트가 테스트 프로젝트에서 수행하는 네 가지 작업

첫 번째 흐름 작성

e2e 테스트의 모범 사례는 절대 깨져서는 안 되는 흐름의 짧은 목록으로 시작하므로, FlowLatch에게 해당 흐름만 작성하도록 요청하세요. list_dir과 glob은 기존 테스트의 이름 패턴을 보여주고, read_file은 하나의 파일을 패턴으로 열어보며, write_file은 테스트 계정과 가짜 데이터가 포함된 로그인 흐름의 새 파일을 생성합니다. Shell이 테스트 명령을 실행하면 카드에 실제 종료 코드가 표시됩니다. 첫 초안은 최종이 아닐 수 있으므로 한 번에 하나의 변경(예: 더 명확한 이름이나 페이지 텍스트 확인 추가)을 요청하세요. 수락하기 전에 diff에서 새 파일을 읽고 직접 한 번 실행한 후, 의도한 흐름과 일치할 때만 유지하세요.

테스트 스위트 실행 및 실패 분석

Shell이 테스트 명령을 실행하고 카드는 전체 출력을 유지하므로 빨간색 결과는 추측이 아닙니다. grep은 실패한 단계를 찾기 위해 출력을 검색하고, 프레임워크가 스크린샷을 저장한 경우 ocr이 그 안의 메시지를 읽습니다. 엔드투엔드 테스트의 불안정성을 줄이려면 FlowLatch에게 동일한 명령으로 실패한 테스트를 다시 실행하고 종료 코드를 비교하도록 요청하세요. 통과 후 실패로 이어지면 고정된 대기 조건, 공유 테스트 데이터 또는 테스트 순서가 원인일 수 있습니다. 채팅에서 짧은 설명을 요청한 후 파일을 변경하기 전에 출력과 대조해 검토하세요.

레이아웃 변경 후 셀렉터 수리

프론트엔드 작업에 e2e 테스트가 시간 대비 가치가 있는지 여부는 흐름에 달려 있으므로, 먼저 로그인과 체크아웃을 커버하세요. 페이지 레이아웃이 변경되면 grep은 관련 셀렉터를 모두 찾고, read_file은 주변 단계를 보여주며, edit_file은 안정적인 레이블이나 테스트 ID를 제안합니다. Ask first 모드에서 FlowLatch는 각 편집 전에 일시 정지하고 파일별로 diff를 보여줍니다. 맞는 줄은 수락하고 나머지는 거부한 후, Shell이 다시 전체 테스트를 실행하게 하여 새로운 종료 코드를 확인하세요. 검토자가 1분 안에 읽을 수 있도록 diff를 작게 유지하세요.

다른 프레임워크로 스위트 이동

프레임워크 간 e2e 테스트 마이그레이션 시 새 스위트가 통과할 때까지 두 스위트 모두 저장소에 유지하세요. FlowLatch는 glob으로 기존 테스트를 나열하고, read_file로 각각을 읽으며, write_file로 새 파일을 하나씩 작성합니다. web_search와 http_get은 기억나지 않는 구문을 위해 새 프레임워크의 자체 문서를 읽을 수 있습니다. Shell로 두 스위트 모두 실행하고 종료 코드를 비교한 후, 기존 스위트가 제거되기 전에 Ask first에서 각 파일을 승인하세요. 계획은 재시작 후에도 유지되므로 긴 마이그레이션은 다음 날 계속할 수 있습니다.