테스트 생성과 검증이 매주 수작업이 되는 이유#
테스트 코드를 자동으로 만들더라도 기대 결과가 요구사항과 다르면 잘못된 테스트가 통과할 수 있습니다. 정상 입력뿐 아니라 경계값과 오류 처리도 요구사항을 기준으로 확인하세요.
작업 전 안전 확인: 비밀번호·토큰 등 비밀정보와 고객 데이터는 파일, 프롬프트, 로그에서 제외합니다.
| 확인 대상 | 테스트에 담을 내용 | 검토할 점 |
|---|---|---|
| 정상 입력 | 대표 입력과 기대 결과 | 결과가 실제 요구사항과 일치하는가 |
| 경계 입력 | 최솟값·최댓값과 그 밖의 값 | 허용 범위가 명확한가 |
| 오류 입력 | 실패 조건과 기대 오류 | 예외를 삼키거나 무조건 통과하지 않는가 |
| 회귀 | 이전 결함의 재현 조건 | 수정 전 실패하고 수정 후 통과하는지 확인했는가 |
테스트 케이스와 검증 메서드의 예시는 Python unittest 공식 문서를 참고하세요. 실제 프로젝트에서는 사용하는 언어와 테스트 프레임워크에 맞춥니다.
테스트 생성 전 계획과 실행 후 검토#
작업 전에는 유지할 동작과 기존 테스트를 확인하고, 작업 후에는 추가된 테스트의 기대값과 실제 실행 결과를 비교합니다. 자동화 후의 시간 절감이나 품질 개선은 이 글에서 측정하지 않았습니다.
| 확인 결과 | 기록할 내용 | 다음 조치 |
|---|---|---|
| 통과 | 실행 명령, 검증한 입력과 기대값 | 기대값과 누락된 조건을 사람과 대조 |
| 실패 | 명령, 민감정보를 지운 출력, 재현 조건 | 기존 실패인지 새 실패인지 구분 |
| 건너뜀·미실행 | 이유와 필요한 환경 | 통과로 표시하지 않고 별도 확인 |
기능 구현 가이드는 실행한 검사와 실행하지 못한 검사를 구분하도록 안내합니다.
단계별로 하기: 입력 규칙 → 실행 → 검증#
- 대상 함수와 유지할 동작, 입력 범위, 기대 결과를 적고 기존 테스트와 실행 명령을 확인합니다.
- Mirr Code에 정상·경계·오류 사례를 기존 테스트 방식에 맞춰 작성해 달라고 요청합니다. 먼저 제안만 검토하려면 Plan 모드를 사용할 수 있습니다.
- 변경된 테스트와 기대값을 사람이 검토한 뒤, 안전한 환경에서 프로젝트의 테스트 명령을 실행하도록 요청합니다.
- 실행 명령과 통과·실패·건너뛴 항목을 확인하고, 실행하지 못한 검사는 별도로 남깁니다. 기능 구현 가이드도 이 구분을 권합니다.
커버리지 높이기: 누락 분기를 찾아 검증하기#
커버리지 높이기는 비율만 올리는 작업이 아닙니다. 같은 소스 범위와 제외 규칙으로 현재 실행 경로를 측정하고, 빠진 분기에 요구사항을 검증하는 테스트를 추가하는 절차입니다. 이 절의 1~5단계는 Python unittest와 coverage.py를 사용하는 프로젝트의 미실행 예시이며 다른 언어에는 해당 도구의 공식 측정 방법을 적용하세요.
- 대상 커밋, Python·coverage.py 버전, 테스트 명령, 측정할 소스와 제외 규칙을 기록합니다. 기존 결과는 덮어쓰기 전에 별도로 보관하고, 테스트가 DB·네트워크를 바꾸는지 먼저 확인하세요.
- 승인된 격리 환경에서 기존 테스트를 분기 측정과 함께 실행합니다. 다음 예시는 현재 디렉터리의 소스를 측정하며 프로젝트의 테스트 구조에 맞춰 범위를 조정해야 합니다.
python3 -m coverage run --branch --source=. -m unittest discover
python3 -m coverage report -m
- 보고서의
Miss,Branch,BrPart와Missing을 읽고 누락된 줄·분기를 코드와 대조합니다.Missing의 화살표는 실행되지 않은 분기 경로를 나타냅니다. 조건의 반대쪽, 빈 값·오류·경계 입력 중 실제 요구사항에 해당하는 것을 고르세요. - Mirr에는 누락 위치와 기대 동작을 주고 정상·오류 테스트를 기존 방식에 맞춰 제안해 달라고 요청합니다. 기대값을 구현의 반환값에서 그대로 복사하지 말고 요구사항에서 독립적으로 정합니다. 결함 수정이라면 수정 전 재현 실패와 수정 후 통과를 따로 확인하세요.
- 같은 환경·소스·제외 규칙으로 다시 측정하고 새 테스트의 assertion, 전체 테스트 성공 여부와 남은 미측정 경로를 함께 검토합니다. 코드를 측정 대상에서 빼거나 제외 규칙을 늘려 오른 비율을 테스트 개선으로 보고하지 마세요.
| 보고서에서 본 것 | 보강할 검증 | 전후 비교할 근거 |
|---|---|---|
| 실행되지 않은 줄 | 진입 조건과 기대 출력·오류 | 같은 파일 범위의 실행 여부와 테스트 결과 |
| 일부만 실행된 분기 | 조건의 반대쪽·오류 경로 | 누락 분기와 실제 assertion |
| 제외·미측정 코드 | 설정·생성 코드·환경 의존성의 제외 이유 | 같은 제외 규칙인지와 여전히 빠진 범위 |
| 비율만 상승 | assertion 없는 호출이나 측정 범위 변경 여부 | 요구사항을 검증하는 diff와 측정 설정 |
근거: coverage.py 시작 안내, 분기 측정, 누락 분기 보고서(2026-11-02 문서 확인). 명령은 측정 파일을 만들거나 기존 기본 측정 데이터를 갱신할 수 있습니다. 이 글에서는 실행하지 않았으며 전후 비율·개선 수치를 제공하지 않습니다. 높은 커버리지는 assertion의 정확성이나 결함 부재를 보장하지 않습니다.
검증: 테스트 출력과 체크리스트#
다음은 실행하지 않은 예시입니다. 허용 범위 1~3의 경계를 확인하는 Python 표준 기능만 쓴 짧은 코드와 그 기대 출력을 적었으며, 이 글의 작업에서 실행해 얻은 결과가 아닙니다. AI가 생성한 테스트나 실제 프로젝트의 통과 기록도 아닙니다.
$ python3 -B - <<'PY'
def valid_count(value):
return 1 <= value <= 3
for value, expected in [(0, False), (1, True), (3, True), (4, False)]:
actual = valid_count(value)
assert actual == expected, (value, expected, actual)
print(f'{value}: expected={expected}, actual={actual}')
PY
0: expected=False, actual=False
1: expected=True, actual=True
3: expected=True, actual=True
4: expected=False, actual=False
이 예제는 네 입력만 확인하며 요구사항 자체의 정확성이나 다른 입력을 보장하지 않습니다. 2026-11-03 「실제 생성 테스트가 놓친 조건과 감독하의 보강」 절의 Mirr 합성 CSV 과제 실행 기록은 이 독립 Python 예제와 다른 과제이며 실제 업무와 CI 검증을 대신하지 않습니다. 업무 저장소의 assertion 없는 테스트 보강 diff와 CI 실행 화면은 아직 없습니다.
주의할 점과 한계#
커버리지가 높거나 테스트가 통과해도 기대값이 옳다는 뜻은 아닙니다. 외부 서비스 호출, 데이터 변경, 인증 정보가 포함된 테스트는 실행 범위와 안전한 환경을 먼저 확인하세요.
구현과 독립적인 기대값 만들기#
테스트 생성 요청에 함수 코드만 주면 모델이 현재 구현을 정답으로 따라 쓸 수 있습니다. 먼저 요구사항에서 입력과 기대 결과를 적으세요. 예를 들어 허용 개수가 1부터 3까지라면 0과 4는 거부하고 1과 3은 허용한다는 표를 사람이 먼저 검토합니다. 코드가 현재 무엇을 반환하는지와 업무가 요구하는 결과를 구분해야 합니다. 기대값을 대상 함수로 계산한 뒤 같은 함수의 결과와 비교하는 테스트는 결함을 독립적으로 확인하지 못합니다.
오류 조건도 같은 방식으로 정합니다. 잘못된 입력에서 예외가 필요한지, 오류 값을 반환해야 하는지, 외부 쓰기가 없어야 하는지 명시하세요. 오류가 났다는 사실만 검사하면 잘못된 이유로 실패한 코드가 통과할 수 있습니다. 반대로 특정 오류 문구 전체를 고정하면 의미 없는 문구 수정에도 테스트가 깨질 수 있습니다. 팀의 공개 계약에 맞춰 오류 타입, 코드와 중요한 필드 중 무엇을 검증할지 정합니다.
| 생성된 테스트의 위험 신호 | 왜 부족한가 | 검토할 보강 |
|---|---|---|
| 함수를 호출하기만 함 | 결과와 부작용이 틀려도 통과 가능 | 요구사항의 출력·오류 assertion |
| 기대값을 같은 구현으로 계산 | 구현 오류를 그대로 복제 | 사람이 검토한 독립 기대값 |
| 모든 예외를 잡고 종료 | 실패를 성공처럼 숨김 | 예상 오류만 검사하고 나머지는 전파 |
| mock 호출만 검사 | 사용자에게 보일 결과가 빠질 수 있음 | 반환 계약과 중요한 부작용 확인 |
| 무조건 스냅샷 갱신 | 바뀐 동작을 승인해 버림 | 변경 이유와 각 기대값의 의미 검토 |
이 표는 생성된 테스트를 거르는 기준입니다. mock이나 스냅샷이 항상 나쁘다는 뜻은 아닙니다. 어떤 계약을 검증하고 어떤 경계를 대체했는지 설명할 수 있어야 합니다. 같은 동작을 여러 입력으로 반복 검사하는 경우도 입력의 차이가 실제 분기를 만드는지 확인하세요. 테스트 개수만 늘고 검증하는 요구사항은 그대로라면 커버리지와 유지 비용을 함께 검토할 필요가 있습니다.
수정 전 실패를 확인하는 회귀 테스트#
결함 수정에는 원래 결함을 재현하는 검사가 필요합니다. 먼저 승인된 비식별 입력으로 실패 조건을 만들고 수정 전 코드에서 왜 실패하는지 확인하세요. 테스트 환경 자체의 오류나 잘못된 경로 때문에 실패한 것은 결함 재현이 아닙니다. 실패 출력과 기대 결과를 대조한 다음 구현을 고칩니다. 수정 후 같은 검사에서 통과하는지 보고 다른 정상 동작도 유지되는지 확인합니다. 이 순서를 실제로 수행하지 않았다면 실패→통과 기록이 있다고 쓰지 마세요.
회귀 입력은 작고 원인을 드러내는 편이 좋습니다. 실제 고객 로그를 통째로 가져오기보다 문제를 만드는 필드와 조건만 남긴 합성 자료를 검토하세요. 단, 줄이는 과정에서 중요한 조건을 없애면 재현이 사라질 수 있습니다. 시간대, 빈 문자열, 정렬 순서와 중복 키가 영향을 주는지 확인합니다. 재현이 불안정하면 즉시 테스트를 건너뛰도록 바꾸기보다 외부 상태와 시간 의존성을 먼저 조사하세요.
경계값과 상태 조합의 우선순위#
모든 입력 조합을 검사하기 어려우면 공개 계약의 경계와 위험이 큰 상태부터 고릅니다. 길이 제한이면 경계 바로 안과 밖, 페이지 처리면 첫 페이지·마지막 페이지·빈 결과, 권한이면 허용 계정·다른 대상·권한 없는 요청을 나눌 수 있습니다. 이들은 설계 예시이며 실제 서비스 권한 검증을 했다는 뜻은 아닙니다. 기대 결과가 애매하면 코드를 쓰기 전에 요구사항 담당자에게 확인할 질문으로 남겨야 합니다.
상태가 이어지는 기능은 한 번의 호출만으로 충분하지 않을 수 있습니다. 같은 입력을 두 번 처리했을 때 중복 쓰기가 생기는지, 실패 뒤 다시 실행할 때 이전 상태가 남는지 살펴보세요. 테스트는 격리된 임시 파일과 승인된 대체 서비스로 구성할 수 있지만 그 결과를 운영 환경의 성공으로 일반화하면 안 됩니다. 외부 DB나 네트워크를 실제로 쓰는 검사는 별도 환경과 승인이 필요합니다. 로컬 단위 테스트가 통과했다고 그 검사를 대신할 수 없습니다.
커버리지 보고서와 품질 판단을 연결하기#
누락된 줄이 보이면 그 줄에 들어가는 업무 조건부터 읽습니다. 테스트 하나를 추가해 줄을 실행했다고 기대 결과까지 검증된 것은 아닙니다. 분기 측정에서 빠진 경로가 발견되면 해당 조건이 실제 요구사항에 속하는지와 테스트 환경에서 도달 가능한지 확인하세요. 생성 코드나 환경별 코드의 제외 이유도 기록합니다. 전후 비교에서는 소스 범위, 제외 규칙과 도구 버전이 같아야 비율 변화의 의미를 설명할 수 있습니다.
커버리지 목표를 맞추려고 assertion 없는 호출을 추가하거나 오류를 무시하면 보고서만 좋아질 수 있습니다. 구현의 조건을 일부러 잘못 바꿨을 때 중요한 테스트가 실패하는지 검토하는 방식도 테스트의 민감도를 살피는 데 도움이 될 수 있습니다. 다만 그런 실험은 원본과 분리한 승인 환경에서 하고 실제 실행 여부를 기록해야 합니다. 이 글은 mutation 도구를 설치하거나 실행하지 않았으며 새로운 품질 점수를 주장하지 않습니다.
실행 기록을 읽고 인계하는 법#
실행 명령과 종료 상태, 실행된 테스트 수, 실패·건너뜀과 대상 커밋을 함께 보관하세요. 출력의 마지막에 성공처럼 보이는 문장이 있어도 앞에서 오류가 있었을 수 있습니다. 테스트 명령이 실제로 대상 파일을 발견했는지도 확인합니다. 검색 패턴이 틀려 아무 테스트도 돌지 않은 실행을 성공으로 보고하면 안 됩니다. 생성된 테스트 파일이 저장소의 기본 명령에 포함되는지 역시 별도로 확인해야 합니다.
실패는 테스트 오류와 구현 오류, 환경 부족으로 나눕니다. 필요한 서비스가 없어 실행하지 못한 검사를 구현이 틀렸다고 단정하지도, 통과했다고 처리하지도 마세요. CI 설정 예시가 있더라도 실제 CI 실행·비밀값·게시 권한 검증은 별도입니다. 2026-11-03 합성 CSV 기록과는 별개로, 업무 저장소의 assertion 없는 테스트를 보강한 실제 변경과 CI 설정·실행 화면이 있어야 그 프로젝트의 검증 상태를 설명할 수 있습니다. 실행한 검사와 여전히 빠진 조건을 보고서에서 나눠 주세요.
assertion 없는 테스트를 보강하는 검토 예시#
다음 코드는 실행한 Mirr 생성 결과가 아닌 짧은 검토 예시입니다. valid_count(0)을 호출하기만 하는 테스트는 함수가 잘못 True를 반환해도 실패하지 않습니다. 기대 계약을 먼저 정했다면 assert valid_count(0) is False처럼 결과를 확인할 수 있습니다. 다만 이 한 줄이 모든 입력을 검증하는 것은 아닙니다. 경계 안의 값과 반대쪽 경계, 잘못된 타입과 오류 계약은 실제 요구사항에 맞춰 별도로 검토해야 합니다.
# 검토 예시: 호출만 하는 형태
valid_count(0)
# 요구 계약이 정해졌을 때 결과를 검사하는 형태
assert valid_count(0) is False
assert valid_count(1) is True
assert valid_count(3) is True
assert valid_count(4) is False
앞의 예시 출력은 이 네 입력의 기대값을 적은 것이며 실행한 기록이 아닙니다. 이 코드 블록 자체를 새로 생성된 테스트 diff나 CI 실행 화면이라고 부르지 않습니다. 특히 Python의 assert는 최적화 실행 옵션의 영향을 받을 수 있으므로 실제 프로젝트에서는 사용하는 테스트 프레임워크와 실행 명령을 확인하세요. 테스트를 실행했다는 기록에는 정확한 명령과 옵션이 필요합니다. 예제의 논리를 그대로 모든 환경에 복사하기보다 기존 검사 방식을 따르는 편이 좋습니다.
테스트가 과도하게 내부 구현을 고정하는 경우#
함수의 내부 호출 순서와 지역 변수까지 검증하면 동작을 보존한 리팩토링에도 테스트가 깨질 수 있습니다. 공개 결과와 중요한 부작용을 기준으로 무엇을 고정할지 정하세요. 외부 호출 횟수나 순서가 비용과 정확성에 영향을 주는 경우에는 그것도 계약일 수 있습니다. 모든 mock 검사를 지우라는 뜻은 아닙니다. 왜 그 검사가 필요한지 요구사항과 연결할 수 있어야 합니다. 테스트를 덜 깨지게 만드는 목적만으로 중요한 검증을 삭제하지 마세요.
AI에게 테스트 수정을 요청할 때는 실패 출력만 주지 말고 보존할 계약을 함께 전달합니다. 현재 구현에 맞춰 기대값을 바꾸라는 요청과 요구사항에 맞는 검사를 고치라는 요청은 다릅니다. 실패 원인이 테스트의 잘못된 가정인지 구현의 회귀인지 먼저 분류하세요. 미실행 상태에서는 어느 쪽이 맞는지 단정하지 않습니다. 작은 테스트의 기대값을 사람이 읽고 설명할 수 있는 상태를 유지하는 것이 생성량보다 중요합니다.
테스트 이름에는 조건과 기대 동작을 넣으면 실패를 읽기 쉽습니다. 예를 들어 “경계 테스트”보다 “최대 허용값 바로 밖의 입력을 거부한다”처럼 무엇이 달라졌는지 설명하세요. 이름과 assertion이 같은 조건을 검사하는지도 확인해야 합니다. 데이터를 여러 행으로 나눴다면 각 행의 실패 식별자를 남겨 원인을 찾을 수 있게 합니다. 이름을 자세히 썼다는 사실은 검사 범위가 넓다는 증거가 아니므로 실제 입력과 기대값을 계속 대조해야 합니다. 기존 프로젝트의 명명 규칙과 출력 형식도 함께 따르세요.
실제 생성 테스트가 놓친 조건과 감독하의 보강#
2026-11-03 실행 기록에는 설치된 Mirr v0.6.15가 작은 합성 CSV 모듈을 작성하고 Node 테스트를 실행한 사례가 있습니다. 최초 생성한 13개 검사가 통과했지만 별도 독립 수락 검사 9건 중 6건이 실패했습니다. 금액의 +1, -0, 0x10, 1e3을 받아들이고 요청하지 않은 연도 제한을 둔 것이 문제였습니다. 생성한 검사와 구현이 함께 통과해도 독립 계약을 만족하지 않을 수 있다는 구체적인 관찰입니다.
coordinator가 실패 조건을 모델에 전달하는 별도 교정 요청을 했습니다. 금액 문법은 ASCII 숫자만, 날짜의 연도 범위는 0001~9999이며 0000은 제외한다고 명시했습니다. 기존 검사를 보존하면서 회귀 검사를 13개 추가했고, 교정 전에는 전체 26개 중 9개가 실패한 뒤 수정 후 26개가 통과했습니다. 마지막 독립 확인은 처음 실패를 찾았던 동일한 9개 수락 사례를 같은 기대값으로 다시 실행한 것입니다. 새로 고른 비공개 평가 과제가 아닙니다. 별도로 CRLF 입력과 저장 결과를 문자 그대로 비교해 통과를 기록했습니다. 모델의 무감독 첫 시도 성공으로 설명하면 안 됩니다.
처음 구현 전의 13개 실패는 모듈이 없어서 난 오류였습니다. 그것만으로 의도한 결함 동작을 테스트가 잡았다고 주장할 수 없습니다. 첫 구현 뒤에는 오류 메시지 assertion 하나도 실패했고 수정 뒤 생성 검사만 통과했습니다. 이 순서를 남겨야 실제 실패→수정과 테스트 환경 부족을 구분할 수 있습니다. 최종 26개는 해당 작은 fixture의 테스트 수이며 웹사이트 전체 검사 수나 품질 점수가 아닙니다.
입력은 인용 없는 고정 세 열 CSV이고 합성 결과의 행 수 3, 합계 4000, 개발 2500·영업 1500도 실제로 저장된 예시 값입니다. 일반 CSV 전체, Excel·HWPX, CI·운영과 외부 서비스의 성공을 보여 주지 않습니다. 동일한 독립 검사 9건의 재통과 역시 시험하지 않은 모든 입력의 정확성을 보장하지 않습니다. 업무 저장소의 CI 설정·실행 화면도 아직 없습니다.
다음에 읽을 것#
실패를 재현하고 원인을 좁히는 방법은 오류 조사 가이드를 참고하세요.
관련#
편집 메모 (2026-11-02): 통과하는 잘못된 테스트의 진단을 보충했습니다. 이후 추가한 2026-11-03 합성 CSV 사례에는 실제 Mirr 생성 테스트의 실패·통과, 독립 검사에서 드러난 여섯 실패와 별도 요청에 따른 보강·수정, 동일한 아홉 수락 사례의 재검사가 있습니다. 기존 독립 Python 기대 출력 예시(미실행)는 이 Mirr 과제와 별개입니다. 업무 저장소에서 assertion 없는 테스트를 보강한 실제 diff, 해당 프로젝트의 CI 설정·실행과 화면은 아직 없습니다. 합성 과제의 통과로 이 범위를 완료 처리하지 않습니다.