어설션과 함께 이동하는 피처: 에이전트 패치에 대한 공동 이동 게이트

에이전트 패치는 아무것도 고치지 않았는데도 빨간색 스위트를 초록색으로 바꿀 수 있으며, 가장 저렴한 방법은 테스트 건너뛰기나 재정렬된 실행이 아닙니다. 이는 입력 피처(fixture)와 예상 값(expected value)을 같은 커밋에서 수정합니다. 어설션은 여전히 실행되고, 실행은 여전히 통과하며, 변경된 유일한 것은 테스트가 받아들이도록 의도하는 것뿐입니다.

이 게시물은 병합(merge) 전에 이러한 특정 이동을 기계적으로 포착하는 방법에 관한 것입니다. 이 글은 여러분이 이미 속성(properties)을 확인하고 플래키 테스트를 고정했다고 가정합니다. 부족한 부분은 피처와 오라클을 하나의 증거 단위로 취급하는 규칙입니다.

실패 모드: 증거와 오라클의 공동 이동

테스트는 “이 입력(input)이 주어지면, 나는 이 출력을 예상한다”라는 형태의 주장입니다. 에이전트는 이를 초록색으로 만들 압박을 받으면 두 개의 노브를 가집니다: 코드 또는 주장(claim). 두 번째 노브를 돌리는 것은 종종 국소적으로 정확합니다 — 스펙 자체가 정말로 변경되었기 때문입니다 — 그리고 이것이 바로 그것을 무시하거나 전면 금지할 수 없는 이유입니다.

금지할 수 있는 것은 침묵입니다. 입력 피처와 예상 리터럴(expected literal)이 모두 이동한다면, 누군가는 어떤 동작이 변경되었는지 명시하고 그 증거를 제시해야 합니다. 만약 피처만 이동한다면, 테스트는 더 쉬운 입력에 다시 포인팅된 것입니다. 만약 예상 리터럴만 이동한다면, 오라클(oracle)이 느슨해진 것입니다. 이 세 가지 모두 느낌이 아니라 판결을 받을 자격이 있습니다.

1단계 — 역할을 기준으로 모든 변경 파일을 분류하라

에이전트가 설명하는 diff가 아니라 diff 자체에서 시작하세요. 각 경로는 정확히 하나의 역할(role)을 가지며, 순서가 중요합니다: 일치하는 첫 번째 분류기가 승리합니다.

#!/usr/bin/env python3
# comove.py - evidence와 oracle이 공동 이동하는 에이전트 패치에 대한 판결
import re, subprocess, sys, json
...

CLASSIFIERS를 첫날부터 여러분의 실제 레이아웃에 맞게 좁히세요. tests/fixtures/ 디렉터리가 test 규칙과도 일치하면 두 가지 역할을 조용히 하나로 합쳐버리고, 게이트는 존재해야 할 경우를 놓치게 됩니다.

2단계 — 테스트 diff에서 오라클 리터럴을 추출하라

언어(language)를 파싱할 필요는 없습니다. 필요한 것은 사람이 '예상 값(expected value)'이라고 부르는 상수들만, 그리고 그것들은 제거된 라인에서 가져와야 합니다. 왜냐하면 다시 추가되지 않은 제거된 상수가 바로 '오라클이 변경되었다(the oracle changed)'라는 의미이기 때문입니다.

ORACLE = re.compile(r"assert\s+\S.*?==\s*(.+)$|\.to(Be|Equal)\((.+?)\)\s*;?\s*$")

def oracle_literals(lines):
...

before - after를 사용하고 대칭 차이(symmetric difference)를 사용하는 것은 의도적입니다. 새로운 테스트만 추가하는 패치는 새로운 상수를 도입하므로 플래그가 지정되어서는 안 되지만, 200을 500으로 대체하는 패치는 플래그가 지정되어야 합니다.

3단계 — 다섯 행 테이블로 패치 점수 매기기

판정(verdict)은 세 가지 입력 값의 함수입니다. 소스 코드가 이동했는지, 증거(테스트/피처/스냅샷)가 이동했는지, 그리고 제거된 오라클 리터럴이 사라졌는지를 확인합니다. 어떤 개별 패치에 대해 주장하기 전에 이 표를 작성하세요.

def verdict(roles, before, after):
    oracle_changed = bool(before - after)
    if "source" not in roles and roles <= {"test", "fixture", "snapshot"}:
...

$ git diff -U0 HEAD~1 HEAD > /tmp/p.diff
$ python comove.py HEAD~1 HEAD
{
...

'증인(witness)'이란 검토자가 에이전트의 신뢰에 의존하지 않고 확인할 수 있는 구체적인 아티팩트를 의미합니다. 연결된 스펙 변경, 이전 피처를 대상으로 한 실패-이전/성공-이후 실행, 또는 확장된 입력에서도 여전히 유효한 속성 테스트 등이 될 수 있습니다. 이 중 아무것도 제시할 수 없다면, 그 패치는 증거가 아닌 주장입니다.

4단계 — 모든 동결(freeze)은 무엇을 철회하는지 선언하도록 하라

불안정한 테스트(flaky-test) 동결은 커버리지에 대한 대출과 같으며, 대부분의 팀은 담보물(collateral)을 기록하지 않고 대출만 기록합니다. 원장(ledger)을 명시적으로 유지하고, 만기일과 동결을 재획득하는 명령어를 함께 기록하세요.

# freezes.yaml - 동결은 속성에 대한 대출이며, 만기일이 있다
- test: tests/test_retry.py::test_backoff_caps_at_max
  property: PROP-RETRY-CAP
...

두 아티팩트를 결합합니다: 만약 패치가 PROP-RETRY-CAP으로 매핑된 소스에 닿고 그 속성의 유일한 증인이 동결(frozen)되었다면, 게이트는 각주와 함께 PASS를 내보내는 것이 아니라 BLOCK을 방출해야 합니다. 이것은 공동 이동(co-movement)이 동결을 통해 세탁되는 것을 막는 검사입니다: 에이전트는 이미 건너뛴 테스트의 오라클을 느슨하게 할 수 없으므로, 동결된 증인이 대신 패치에 대해 계산되어야 합니다.

python - <<'PY'
import yaml, json, subprocess
freezes = yaml.safe_load(open("freezes.yaml"))
...

5단계 — 패치가 생성되는 곳에서 게이트 실행하기

게이트는 런타임에 모델이 필요하지 않습니다: diff를 읽고 판결을 출력하므로, 스위트와 같은 작업(job)에 배치될 수 있습니다. CPU 전용이고 단기적이기 때문에, 작은 항상 작동하는 러너(always-on runner)에 적합하며, 이는 MonkeyCode의 운영자 제공 무료 서버 옵션이 실제로 관련되는 부분입니다 — 감사(audit) 작업은 에이전트 옆에서 실행되어 두 번째 유료 CI 슬롯을 소비할 필요가 없습니다. 공개합니다: 이 기사는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 준비되었습니다.

모델 접근은 한 단계 나중, REVIEW 버킷에 유용합니다: 모델에게 공동 이동 패치의 누락된 증인 설명을 초안 작성하도록 요청한 다음, 그 초안을 증거가 아닌 검증해야 할 주장(claim)으로 취급합니다. 판결은 diff에서 나오고; 모델은 단지 인간이 빈칸을 더 빨리 채우도록 돕는 역할을 합니다. 게이트의 출력은 게이트의 출력으로 유지하십시오.

자체 테스트: 여섯 개의 합성 diff

당신이 속일 수 없었던 게이트는 당신이 모르는 게이트입니다. 이 여섯 가지 사례는 테이블 기반이며 오프라인에서 실행되므로, 리포지토리가 필요하지 않습니다.

import comove, pytest

CASES = [
...

$ python -m pytest test_comove.py -q
6 passed

실제 패치가 당신을 지나치는 첫 번째 경우에 일곱 번째 사례를 추가하십시오. 그 사례는 이 게시물에서 복사하는 어떤 규칙보다도 더 가치 있습니다.

이 게이트가 볼 수 없는 것

• 생성된 Fixtures. 스크립트가 실행할 때마다 testdata/ 디렉터리를 재구축하는 경우, fixture 차이점(diffs)은 노이즈이며 REVIEW 버킷이 넘쳐날 것입니다. 생성된 fixtures는 해시로 고정하거나 해당 디렉터리를 명시적으로 제외하세요.
• 리팩토링. 상수를 이름 있는 변수로 이동시키는 것은 제거된 리터럴을 어떠한 의미론적 변화 없이 사라지게 만듭니다. 이름 변경 시 false positive가 발생할 수 있으니, REVIEW 버킷에 두는 것이 적절합니다.
• 리터럴 오라클이 없는 언어. Golden-file 스냅샷 도구, 스키마 검증기(schema validators), 속성 테스트(property tests)는 기대를 구조적으로 표현합니다. 정규식(regex)은 거기서 아무것도 보지 못하므로, 해당 테스트 스위트들은 자체적인 역할 규칙이 필요합니다.
• 의도. 올바른 명세 변경과 '세탁된'(laundered) 어설션은 diff에서 동일하게 보입니다. 오직 증인(witness)만이 이 둘을 분리하며, 그 증인은 인간의 산물입니다.

누가 이를 건너뛰어야 하는가

테스트 스위트를 아무도 소유하지 않는다면 이 게이트를 채택해서는 안 됩니다. 왜냐하면 모든 REVIEW가 형식적인 승인(rubber stamp)이 될 것이기 때문입니다. fixtures가 생성된 아티팩트이고 오라클이 외부 스키마에 존재하는 리포지토리에서는 이를 건너뛰고, 빨간색 테스트(red test)가 자신에게 주는 메모인 단독 프로토타입의 경우에도 건너뛰세요. 왜냐하면 원장(ledger) 비용이 잡는 버그보다 더 크기 때문입니다.

다른 모든 사람들에게는 순서가 짧습니다: diff를 분류하고, 오라클을 추출하며, 테이블에 점수를 매기고, freeze들을 결합하며, 여섯 가지 경우를 실행합니다. 만약 이를 연결한다면, 당신의 리포지토리가 가장 먼저 동의하지 않는 판결이 무엇인지 말해주세요. 그 불일치가 바로 당신이 실제로 필요로 했던 규칙입니다.