사용자의 앱은 증거와 함께 제공됩니다
Kliv는 자신이 빌드한 앱에 대한 실제 테스트를 작성하고 모든 부작용에 대한 영수증과 함께 데이터베이스의 일회용 복사본에 대해 실제 브라우저에서 실행합니다. 앱을 작성하는 동일한 루프가 테스트를 작성하고 이를 녹색으로 만듭니다.
내장 테스트
생성되지 않은 코드 및 교차된 손가락
대부분의 AI 빌더는 앱을 생성하여 전달합니다. 실제로 작동하는지 여부가 문제입니다. Kliv는 브라우저, API, 보안 규칙, 데이터베이스, 이메일 파이프라인 등 앱이 실행되는 전체 스택을 소유합니다. 그래야 증명이 가능합니다. 테스트는 나중에 시작하는 것이 아닙니다. 이는 앱이 구축되는 방식의 일부이며 코드를 작성한 동일한 루프에 의해 실행됩니다.
달리기의 구조
테스트 시스템을 이해하는 가장 좋은 방법은 첫 번째 줄부터 판정까지 한 번 실행해 보는 것입니다. 실제 데이터에는 영향을 미치지 않는 일이 발생합니다.
쓰기
AI는 구축 시 단위 테스트를 작성합니다. 이는 독점 모방이 아닌 업계 표준 스택인 정품 Vitest 및 테스트 라이브러리입니다. 흐름이 다루어지도록 요청하면 Scenario가 작성됩니다. 의미론적으로 탐색, 클릭, 채우기, 주장(버튼은 이름으로, 필드는 라벨로) 다음 재설계에서 사라지는 부서지기 쉬운 CSS 경로가 아닙니다.
실제 브라우저에서 실행
실제 렌더링, 실제 로그인, 실제 행 수준 보안 등 실제 앱에 대해 실제 브라우저에서 테스트가 실행됩니다. 중요한 것은 조롱되지 않습니다. 권한 변경으로 인해 한 사용자가 다른 사용자의 데이터를 읽을 수 있게 되면 앱이 그랬던 것처럼 테스트가 실패하게 됩니다.
데이터베이스 포크
Scenario는 데이터에 접근하기 전에 동일한 스키마, 동일한 규칙, 위험에 처한 행이 없는 데이터베이스의 일회용 포크를 얻습니다. 실제로 생성, 편집 및 삭제가 실행되고 포크에 도달합니다. 파일과 커머스 상태는 동일한 방식으로 복제됩니다. 런이 끝나면 포크는 버려집니다.
송신 캡처
이메일, 웹후크, 제3자 통화는 캡처되지만 실행되지는 않습니다. 테스트를 통해 환영 이메일이 누구에게, 무엇으로 발송되었는지 확인할 수 있으며 이메일은 건물 밖으로 나가지 않습니다. 논리가 실행되는 동안 연동은 조용히 유지됩니다.
영수증
모든 실행은 앱이 실제로 수행한 작업을 기록합니다. 즉, 작성한 행, 보낸 이메일, 시도한 외부 호출 등 각 항목은 쓰기를 차단한 보안 규칙에 따라 이유도 첨부되어 허용, 캡처 또는 거부로 표시됩니다. 빨간색이나 녹색뿐만 아니라 무슨 일이 일어났는지, 왜 그랬는지
평결
검사별로, 파일별로 결과가 반환됩니다. 즉, 실행 영수증과 함께 실패한 어설션, 중단된 단계가 표시됩니다. 구조적 실패가 핵심입니다. 이는 코드를 작성한 동일한 루프가 실수를 찾아서 수정하고 다시 실행할 수 있도록 하는 것입니다.
게이트
테스트 결과 게이트 게시. 실패한 Scenario는 사용자에게 도달하기 전에 릴리스를 중지합니다. 따라서 “만들었을 때 작동했습니다”가 “지금 작동합니다”가 되며 데모에서 기억하는 대신 모든 변경 사항에 대해 확인됩니다.
테스트 시스템이 수행 방법을 알고 있는 것
내장되어 실행되며 보고 싶을 때 읽을 수 있습니다.
실제 테스트 스택
브라우저에서 실행되는 정품 Vitest, 테스트 라이브러리 및 jest-dom — 전문 팀이 사용하는 것과 동일한 도구이므로 테스트는 공급업체의 방언이 아닌 테스트처럼 읽힙니다.
Scenario 테스트
의미론적으로 작성된 엔드 투 엔드 흐름(역할로 버튼 찾기, 레이블로 필드 찾기)은 사용자가 원하는 방식으로 실제 앱을 구동합니다.
일회용 데이터베이스
모든 Scenario는 실제 데이터베이스의 포크에 대해 실행됩니다. 쓰기가 허용되고, 주장되고, 삭제됩니다. 사용자의 데이터는 결코 실험에 포함되지 않습니다.
누출은 없습니다
테스트 실행에서는 이메일, 웹후크 및 커넥터 호출을 전송하는 대신 캡처합니다. 이러한 일이 발생하지 않고도 발생했음을 증명할 수 있습니다.
모든 실행에는 영수증이 있습니다
테스트로 인해 발생한 모든 부작용(수락, 캡처 또는 거부)에 대한 원장입니다. 신호등뿐만 아니라 흔적.
역사와 문
실행은 시간이 지남에 따라 추적되며 테스트 통과는 게시로 이어집니다. 확인은 일회성 이벤트가 아닌 앱의 정지 상태입니다.
자주 묻는 질문
테스트 작성자는 누구인가요?
AI는 빌드 시 기본적으로 표준 스택에서 단위 테스트를 수행합니다. 처리할 흐름을 요청하면 이에 대한 Scenario가 작성됩니다. 모든 테스트는 앱에서 읽을 수 있는 코드입니다. 무엇이든 검사할 수 있으며 그럴 필요도 없습니다.
테스트가 실제 데이터에 영향을 미치나요?
아닙니다. Scenario는 데이터베이스의 일회용 포크에 대해 실행됩니다. 거기에서 쓰기가 허용되고 실행이 끝나면 포크와 함께 삭제됩니다. 파일과 커머스 상태는 동일한 방식으로 복제되므로 모든 것을 삭제하는 테스트라도 아무것도 삭제되지 않습니다.
테스트에서 실제 이메일을 보내나요, 아니면 연동에 영향을 미치나요?
아니요 — 아웃바운드 트래픽이 캡처되고 전송되지 않습니다. 실행에서는 이메일이 누구에게, 무엇을 통해 전달되었는지 기록하고 테스트에서 이에 대해 주장할 수 있습니다. 고객과 연결된 도구는 테스트를 볼 수 없습니다.
테스트가 실패하면 어떻게 되나요?
검사별 결과(파일, 검사, 실패한 어설션)와 각 허용 또는 거부 이유가 포함된 실행의 부작용 수신. 이 구조를 통해 AI는 스크린샷을 통해 추측하는 대신 자체 실수를 진단하고 수정할 수 있습니다.
테스트에서 보안 규칙이 적용되나요?
예 — 모의 세션이 아닌 실제 행 수준 규칙에 대한 실제 로그인으로 Scenario가 실행됩니다. 변경으로 인해 사용자가 자신의 것이 아닌 데이터를 볼 수 있게 되면 사용자가 보기 전에 테스트가 실패하게 됩니다.
실패한 테스트로 인해 출시가 차단될 수 있나요?
그렇습니다. Scenario는 게이트 게시를 결정합니다. 빨간색 실행은 다시 녹색이 될 때까지 릴리스를 중지합니다. 게이트는 마지막 변경 사항이 안전하기를 바라는 것과 확인되었음을 아는 것 사이의 차이입니다.
앱을 설명하세요. 검증해보세요.
내장된다는 것은 함께 빌드된다는 의미입니다. 테스트는 사용자가 보는 것과 동일한 앱에 대해 실행됩니다. 따라서 실패한 체크아웃 테스트는 가짜 체크아웃이 아니라 실패한 체크아웃입니다.
