바이브 코딩 테스트 완전 정리

테스트 생성은 체감 효율이 가장 큰 영역이지만, 원리상의 약점도 가장 뚜렷합니다. 모델은 구현 코드를 읽고 테스트를 씁니다. 그 코드에 이미 버그가 있으면 버그가 만들어낸 값이 그대로 기대값으로 굳습니다. 사양이 아니라 현재 동작을 검증하는 테스트가 대량으로 생기는 셈입니다. 커버리지 지표는 실행된 줄을 셀 뿐 단언의 질을 세지 않으니, 두 숫자가 함께 올라간 것만으로는 더 안전해졌다는 근거가 되지 못합니다.

그래서 엣지 케이스 자동 발견부터 읽는 편이 좋습니다. 구현을 주지 않고 시그니처와 비즈니스 규칙만 줘서 경계값을 뽑아내는 쪽이 검증력이 훨씬 높습니다. 여기서 나온 목록을 Parameterized Test 케이스를 AI로 대량 생성하라로 표에 채워 넣고, Mock 객체와 테스트 데이터 자동 생성으로 주변 보일러플레이트를 걷어냅니다. 테스트 커버리지 분석 후 누락 케이스를 AI로 생성하라는 마지막에 빈칸을 메우는 용도입니다. 이것을 시작점으로 쓰면 앞서 말한 되읽기 함정에 그대로 걸립니다.

덜 알려진 비용은 과도한 모킹입니다. 협력 객체를 전부 목으로 만들어 달라고 하면 요청한 대로 해주는데, 그 결과 테스트가 프로덕션 코드의 호출 순서와 횟수까지 통째로 고정해 버립니다. 내부 구조만 손보는 리팩터링에도 테스트가 무더기로 깨지고, 정작 실제 연동에서 나는 오류는 하나도 걸러내지 못합니다. 목은 외부 시스템 경계에만 두고 그 안쪽은 진짜 객체로 엮는다는 선을 사람이 미리 정해줘야 합니다.