테스트 생성을 위한 AI: 도움이 되는 부분과 기만하는 부분
AI는 테스트를 빠르게 작성합니다. 하지만 진짜처럼 보이지만 실제로는 잘못된 것을 검증하는 테스트를 작성하기도 합니다.
AI에 함수를 붙여넣습니다. 30초 후, 통과된 12개의 테스트가 생깁니다. 커버리지 점수는 올라갑니다. 생산성이 높아진 기분이 듭니다.
그러다 운영 환경에서 버그가 발생합니다. 그 12개의 테스트를 살펴보니, 그중 어떤 것도 버그를 잡아내지 못했다는 사실을 깨닫게 됩니다.
AI는 코드가 '무엇을 하는지'를 테스트했을 뿐, 코드가 '무엇을 해야 하는지'를 테스트하지 않았습니다.
AI는 유용하지만, 어떻게 사용해야 하는지 반드시 알아야 합니다.
AI가 잘하는 것:
- setup 및 teardown 블록과 같은 보일러플레이트 생성.
- 반복적인 팩토리 헬퍼 및 데이터 객체 작성.
- 하나의 좋은 테스트 패턴을 바탕으로 다양한 변형 생성.
- null, 빈 문자열, 0과 같은 명백한 엣지 케이스 처리.
AI가 못하는 것:
- 구현 기반 테스트: 비즈니스 로직 대신 코드 구조를 따르는 테스트를 작성합니다. 코드를 리팩터링하면 결과가 여전히 올바르더라도 테스트가 깨집니다.
- 얕은 엣지 케이스: 명백한 오류는 찾아내지만 도메인 특화된 버그는 놓칩니다. 타임존의 특이사항, 데이터베이스 제약 조건 또는 특정 비즈니스 규칙을 알지 못합니다.
- 취약한 모킹(Brittle mocks): 실제 상태를 유지해야 하는 내부 서비스까지 모킹합니다. 이로 인해 테스트 유지보수가 느려지고 리팩터링 중에 테스트가 깨지기 쉬워집니다.
"테스트 연극"을 만들지 않고 AI를 사용하는 방법:
- 계약(contract)을 먼저 정의하세요. 테스트가 무엇을 증명해야 하는지 평이한 문장으로 한 줄 작성합니다. 예: "만료된 코드는 원래 금액을 반환해야 한다."
- 그 문장을 AI에게 전달하세요. 코드는 AI가 작성하게 하되, 의도(intent)는 반드시 본인이 소유해야 합니다.
- 경계(boundary)에서만 모킹하세요. 내부 모듈에는 실제 인스턴스를 사용하세요. 외부 API나 데이터베이스만 모킹합니다.
- 도메인 엣지 케이스 하나는 직접 작성하세요. AI는 '명백한' 엣지 케이스를 처리합니다. 실제 운영 환경의 장애를 일으키는 '새벽 3시의' 엣지 케이스는 직접 처리해야 합니다.
AI가 무엇을 검증할지 결정하게 두지 마세요. 코드를 타이핑하는 용도로 사용하되, 로직은 직접 제공해야 합니다.
출처: https://dev.to/nazar_boyko/ai-for-test-generation-where-it-helps-and-where-it-lies-jhm