그래프 기반 권한 부여 서비스를 테스트부터 써서 고치기

## 정확성을 가장 먼저 두고 저장소의 빌드 타깃 사용하기 프로젝트 우선순위를 다음 순서로 적용합니다. 1. 정확성: 모든 권한 부여 결정은 정확해야 합니다. 2. 신뢰성: 서비스는 계속 사용 가능해야 하며 예측 가능한 방식으로 복구되어야 합니다. 3. 성능: 정확성과 신뢰성을 보장한 후에만 지연 시간과 할당을 최소화합니다. 리포지토리가 소유한 빌드 타깃을 단일 진실 공급원으로 취급합니다. 이러한 타깃에는 필수 생성 작업, 플래그, 경합 감지, 커버리지, 린팅, 환경 설정이 포함되므로 임시 명령보다 우선해서 사용합니다. 일반적인 타깃 그룹은 다음을 포함해야 합니다. - 프로덕션 빌드 - 전체 테스트 스위트 - 이름이 지정된 사례에 대한 필터링된 테스트 - 메모리 지표를 포함한 벤치마크 - 컨테이너가 필요한 통합 테스트 - 리포지토리에 설정된 도구 버전을 사용하는 린팅 - 생성된 테스트 대역 - 인메모리 또는 컨테이너 기반 데이터스토어를 사용하는 로컬 개발 타깃을 실행하기 전에 해당 정의와 필수 환경 변수를 읽습니다. 표준 타깃을 사용할 수 없거나 그 내용이 불명확하다면, 더 약한 명령으로 몰래 대체하지 말고 그 공백을 해소합니다. ## 바꾸기 전에 요청이 리졸버 체인을 지나는 길 따라가기 동작을 변경하기 전에 요청이 전체 런타임 경로를 통과하는 과정을 파악합니다. 다음 순서를 따릅니다. 1. HTTP 또는 RPC 요청을 수신합니다. 2. 미들웨어를 적용합니다. 3. 전송 핸들러로 진입합니다. 4. 명령 또는 애플리케이션 서비스를 호출합니다. 5. 권한 부여 그래프를 해석합니다. 6. 스토리지에 접근합니다. 7. 응답을 반환합니다. 시작과 종료, 핸들러, 비즈니스 명령, 그래프 평가, 계획 수립, 스토리지 인터페이스와 구현, 모델 파싱, 튜플 검증, 인증, API 권한 부여를 담당하는 모듈을 찾습니다. 그래프 기반 검사에서는 리졸버 빌더와 리졸버 인터페이스를 함께 살펴봅니다. 리졸버 파이프라인은 설정에서 활성화한 경우에만 캐싱, 디스패치 스로틀링 또는 섀도 비교를 추가할 수 있습니다. 체인이 선형이라고 가정하지 마십시오. 일부 리졸버 시스템은 마지막 리졸버가 첫 번째 리졸버로 돌아가는 순환 위임 체인을 형성합니다. 디스패치 동작을 변경하기 전에 구성 순서, 종료 조건, 선택적 래퍼와 핵심 로컬 검사기 사이의 차이를 확인합니다. 디렉터리 이름이나 설계상의 가정보다 런타임 연결 구성을 더 강력한 증거로 취급합니다. ## lint 이름 규칙을 지키고 감싼 오류를 구별할 수 있게 두기 임포트나 이름을 수정하기 전에 활성 린트 설정을 읽습니다. 다음을 유지합니다. - 생성된 API와 파서에 필요한 별칭 - 설정된 임포트 그룹과 순서 - 불필요한 접두사가 없는 인터페이스 이름 - `NewTypeName` 패턴으로 이름을 지정한 생성자 - `WithPropertyName` 패턴으로 이름을 지정한 함수형 옵션 - `TypeNameOption func(*TypeName)` 형태의 옵션 타입 - 프로젝트의 공개 명명 스타일을 따르는 공개 상수 - 프로젝트의 로컬 명명 스타일을 따르는 비공개 상수와 컨텍스트 키 안정적인 도메인 오류를 센티널 값으로 정의합니다. 오류의 정체성을 훼손하지 않으면서 컨텍스트를 추가합니다. - `var ErrNotFound = errors.New("not found")`와 같은 센티널을 선언합니다. - `fmt.Errorf("load relationship: %w", ErrNotFound)`와 같이 컨텍스트를 추가해 래핑합니다. 일치 여부를 확인할 때는 `errors.Is` 또는 `errors.As`를 사용합니다. 래핑된 오류를 직접 비교하지 말고, 체인이 유실되는 서식 지정 동사로 래핑된 오류를 포맷하지 마십시오. 도메인에서 전송 계층으로의 변환은 명시적인 경계에 둡니다. 명령 로직은 도메인 오류를 반환해야 하며, 전용 변환기가 이를 HTTP 또는 RPC 응답으로 매핑해야 합니다. ## 실패하는 테스트를 먼저 쓰고 권한 부여 매트릭스 테스트 유지하기 동작 변경에는 테스트 주도 개발을 사용합니다. 1. 누락되거나 잘못된 동작을 나타내는 집중된 테스트를 추가합니다. 2. 테스트를 실행하고 의도한 이유로 실패하는지 확인합니다. 3. 테스트를 통과시킬 수 있는 가장 작은 변경을 구현합니다. 4. 집중된 테스트를 실행한 다음 직접 영향을 받는 스위트를 실행합니다. 5. 테스트가 모두 통과한 후에만 리팩터링합니다. 권한 부여 알고리즘에서는 모델, 관계 튜플, 그리고 검사, 객체 목록 조회, 사용자 목록 조회 API의 예상 결과를 정의하는 매트릭스 테스트를 유지합니다. 매트릭스 스테이지에서는 모델과 어설션을 함께 읽을 수 있어야 합니다. 최소 매트릭스 사례는 다음 순서와 의미를 유지해야 합니다. 1. 예를 들어 `viewer_can_read_document`와 같이 테스트 이름을 지정합니다. 2. 스테이지 모델에 `user`와 `document` 타입을 정의합니다. 3. 사용자를 허용하는 `viewer` 관계를 정의합니다. 4. `document:1`, `viewer`, `user:alice` 튜플을 추가합니다. 5. 동일한 객체, 관계, 사용자를 검사하면 `true`가 반환된다고 어설션합니다. 내장된 테스트 자산이 해당 러너에 등록된 상태를 유지합니다. API에 목록 조회 또는 검사 표면이 여러 개 있다면, 한 표면이 다른 표면도 포괄한다고 가정하지 말고 관련된 각 러너를 검증합니다. 그래프의 핫 패스, 리졸버 선택, 스토리지 접근 또는 할당에 민감한 코드를 변경할 때는 벤치마크를 사용합니다. 데이터스토어 고유 동작에는 컨테이너 기반 테스트를 사용합니다. ## 생성된 파일과 다른 저장소의 스키마를 손으로 고치지 않기 생성된 목, 생성된 프로토콜 바인딩 또는 기타 생성된 아티팩트를 직접 수정하지 마십시오. 소스나 생성기를 변경한 다음 표준 타깃을 통해 다시 생성합니다. 하위 서비스 리포지토리에서 외부가 소유한 스키마 정의를 수정하지 마십시오. 해당 스키마를 소유한 리포지토리에서 변경하고 그곳에서 검토한 다음 하위 종속성을 업데이트합니다. 다음과 같은 운영상의 함정을 고려합니다. - 전체 테스트 타깃은 목을 자동으로 다시 생성할 수 있지만, 언어 수준의 테스트 명령을 직접 실행하면 그러지 않을 수 있습니다. - SQL 데이터스토어의 통합 테스트에는 컨테이너 런타임이 필요할 수 있습니다. - 체인이 순환 구조이기 때문에 리졸버 재귀가 의도된 것일 수 있습니다. - 린트 설정 구문은 버전별로 다릅니다. - 스토리지 인터페이스를 변경하려면 모든 백엔드와 해당 공유 계약 테스트를 함께 변경해야 합니다. 필수 생성기, 컨테이너 런타임 또는 상위 스키마를 사용할 수 없다면 누락된 선행 조건을 보고합니다. 완료를 가장하기 위해 파생된 출력을 직접 수정하지 마십시오. ## 새 API 엔드포인트나 스토리지 변경 때 모든 단계 거치기 새 API 엔드포인트의 경우: 1. 소유하고 있는 API 스키마를 업데이트합니다. 2. 전송 핸들러를 추가합니다. 3. 명령 또는 애플리케이션 서비스 로직을 추가합니다. 4. 전송 경계에서 도메인 오류를 매핑합니다. 5. 집중된 테스트와 매트릭스 테스트를 추가합니다. 스토리지 인터페이스를 변경하는 경우: 1. 인터페이스를 업데이트합니다. 2. 공유 스토리지 계약 테스트를 업데이트합니다. 3. 지원되는 모든 백엔드에 변경 사항을 구현합니다. 4. 영향을 받는 인메모리 및 컨테이너 기반 스위트를 실행합니다. 그래프 리졸버를 변경하는 경우: 1. 리졸버 인터페이스를 구현합니다. 2. 빌더 옵션을 추가하거나 업데이트합니다. 3. 조건부 구성과 순환 위임을 검증합니다. 4. 정확성, 스로틀링 또는 캐싱 상호 작용, 종료를 테스트합니다. 5. 핫 패스가 변경될 수 있다면 벤치마크를 실행합니다. 타입 시스템을 변경하는 경우 파싱, 검증, 가중 또는 최적화된 그래프 로직, 관련 검증 테스트를 하나의 일관된 변경으로 함께 업데이트합니다. 완료를 선언하기 전에 diff를 검토하여 생성된 파일이 실수로 수정되지 않았는지 확인하고, 집중된 테스트의 실패가 통과로 바뀌었는지 확인하며, 직접 영향을 받는 표준 타깃을 실행하고, 실행하지 못한 테스트 종류가 있다면 정확한 선행 조건과 함께 기록합니다.