AI가 함수나 화면 흐름을 보고 정상 케이스·경계값·예외 처리를 챙긴 테스트 코드 초안을 대신 써 주는 기술이다. 미뤄 둔 테스트를 채우거나 리팩토링 전에 안전망을 만들 때 특히 쓸모가 있다.
| 종류 | 무엇을 만드나 | 주로 쓰는 도구 |
|---|---|---|
| 단위·통합 테스트 | 함수·모듈을 확인하는 테스트 코드 (Jest, pytest 등) | Claude Code, Cursor, Copilot |
| E2E 테스트 | 브라우저에서 사용자 흐름을 따라가는 테스트 | testRigor, mabl 같은 AI 테스트 자동화 서비스 |
코딩 에이전트에서는 "src/price.ts의 할인 계산 함수에 Jest 테스트를 써 줘. 빈 장바구니, 음수 수량 같은 엣지 케이스도 넣어 줘"처럼 대상, 프레임워크, 꼭 확인할 경우를 함께 적는다. 기존 테스트 파일 하나를 참고하라고 지정하면 이름 짓는 방식과 mock 쓰는 방식도 그에 맞춘다. IDE 도구에서는 함수를 선택하고 테스트 생성 명령을 부르면 초안이 나온다.
| 순서 | 할 일 |
|---|---|
| 1. 생성 | 대상과 확인할 경우를 정해서 요청 |
| 2. 실행 | 바로 돌려서 통과·실패를 확인 |
| 3. 원인 확인 | 실패하면 테스트 문제인지 코드 버그인지 가린다 |
| 4. 검토 | 기대값을 읽어 보고 중복된 테스트를 정리 |
에이전트형 도구는 테스트를 직접 실행하고, 실패하면 고쳐서 다시 돌리는 과정을 알아서 반복한다. 그래서 채팅창에 코드를 붙여 넣는 방식보다 손이 덜 간다.
AI는 지금 코드가 하는 동작을 정답으로 보고 테스트를 쓴다. 그래서 코드에 버그가 있으면 그 버그까지 기대값으로 굳혀 버릴 수 있다. 기대값은 사람이 요구사항과 맞는지 직접 확인해야 한다.
그 밖에도 아무것도 확인하지 않는 어설션, 실제 로직까지 mock으로 바꿔 버린 테스트, 같은 경우를 이름만 바꿔 반복한 테스트가 자주 나온다. 확인하는 방법은 간단하다. 코드를 일부러 한 줄 망가뜨린 뒤 테스트가 실제로 실패하는지 보면 된다. 커버리지 숫자보다 실패를 잡아내는지가 더 중요하다.
| 상황 | 쓰는 방법 |
|---|---|
| 레거시 코드 리팩토링 전 | 현재 동작을 고정하는 테스트를 넉넉히 생성 |
| 새 기능을 TDD로 개발 | 요구사항을 주고 테스트를 먼저 생성한 뒤, 실패를 확인하고 구현 |
| 결제·권한 같은 핵심 로직 | 초안만 받고 기대값은 직접 검토 |
| 요구사항이 아직 불분명할 때 | 생성을 미루고 무엇을 확인할지부터 정한다 |
가장 흔한 건 코딩 에이전트나 IDE에서 방금 짠 코드의 테스트를 함께 받아 내는 방식이다. 브라우저에서 도는 사용자 흐름 테스트는 별도의 AI 테스트 자동화 서비스에 맡기는 경우가 많다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코딩 에이전트 | 기능을 구현하면서 테스트도 쓰게 하고, 직접 돌려 통과할 때까지 고치게 한다 |
| IDE | 함수를 선택해 테스트 초안을 받고, 기존 테스트 파일 스타일에 맞춰 다듬는다 |
| PR 올리기 전 | 바뀐 코드에서 빠진 경계값·예외 테스트를 채워 함께 올린다 |
| 웹 서비스 QA | 로그인·결제 같은 흐름을 말로 설명해 E2E 테스트를 만들고 배포 전에 돌린다 |