이득:
- 수용 규칙과 독립적으로 단위 테스트에서 기대값을 계산하여 인공지능이 잘못된 동작을 '올바른' 것으로 받아들이는 것을 방지하는 기능
- AAA 및 FIRST 원칙을 적용하고 외부 종속성을 모의하여 빠르고 독립적이며 반복 가능한 테스트를 인쇄하는 기능
- Mutation(코드 깨짐)이 있는 테스트를 테스트하고 테스트하기 어려운 코드를 디자인 냄새로 인식하는 기능
테스트 피라미드의 가장 크고 가장 빠른 계층은 단위 테스트입니다. 즉, 다른 모든 것과 별도로 기능이나 작은 코드 조각을 확인하는 테스트입니다. 수천 개의 단위 테스트가 몇 초 만에 실행되며 코드가 개발자 화면에 있는 동안 버그를 포착합니다. 인공 지능(AI)은 아마도 단위 테스트 생성에 가장 능숙할 것입니다. AI에 기능을 제공하면 AI는 수십 개의 테스트를 생성합니다. 그러나 이러한 편리함은 가장 큰 함정을 야기합니다. AI는 "녹색으로 빛나지만 아무것도 확인하지 않는" 테스트를 쉽게 생성하거나 코드의 현재(아마도 잘못된) 동작을 "올바른" 것으로 받아들이는 테스트를 쉽게 생성합니다. 이 단원에서는 AI를 사용하여 진정한 보호 단위 테스트를 작성하는 방법과 테스트 가능한 코드와 AI 간의 관계를 배웁니다.
좋은 단위 테스트의 조건: FIRST
좋은 단위 테스트는 FIRST 원칙을 따릅니다. 신속, 독립적(테스트는 서로 종속되어서는 안 됨), 반복 가능(반복 가능 - 모든 환경에서 동일한 결과), 자체 검증(명확한 통과/실패), 적시(제때). AI가 테스트를 생성하도록 할 때 다음 원칙을 기억하세요. 특히 테스트가 "독립적"이고 "반복 가능"하기 위해 외부 세계(실제 데이터베이스, 네트워크, 시계)에 의존하지 않도록 요청하세요.
AAA 패턴과 표현력 있는 주장
견고한 단위 테스트는 다음과 같은 AAA 구조를 따릅니다. 배열(준비 - 입력 및 종속성 설정), 실행(실행 - 테스트 중인 함수 호출), 어설션(검증 - 결과를 예상 값과 비교). 중요한 것은 주장입니다. AI가 저지르는 가장 일반적인 실수는 테스트 중인 코드의 출력에서 "코드가 반환하는 것은 무엇이든 참입니다"라는 논리를 파생시키는 것입니다. 이로 인해 테스트가 의미가 없게 됩니다. 올바른 방법은 예상 값을 독립적으로 결정하는 것입니다(허용 기준에서 수동으로 계산).
주의: AI에게 "이 함수에 대한 테스트를 작성하세요"라고 지시하면 AI가 함수를 실행하고 그 출력을 "예상"으로 쓸 수도 있습니다. 이 테스트는 함수가 false인 경우에도 통과됩니다. 대신 "이러한 규칙에 따라 예상 결과를 계산하고 함수의 현재 출력을 참조하지 마세요"라고 말하세요.
모의, 스텁 및 종속성
단위 테스트에는 격리가 필요합니다. 함수가 데이터베이스나 API에 의존하는 경우 테스트 시 모의 객체(모의/스텁 - 실제 종속성을 제어하는 더미 대체물)로 대체됩니다. 이는 테스트를 신속하고 독립적이며 재현 가능하게 만듭니다. AI는 모의 설치를 생성할 수 있습니다. 그러나 과도한 모의에 주의하십시오. 모든 것을 모의하는 경우 테스트에서는 실제 논리가 아닌 "모의가 반환하는 것"만 확인합니다. 균형: 외부 세계를 에뮬레이션하고 테스트 중인 실제 논리를 실행합니다.
테스트 가능성과 AI
흥미로운 피드백이 있습니다. 테스트하기 어려운 코드는 잘못 설계된 코드인 경우가 많습니다. AI가 함수에 대한 테스트를 작성하는 데 문제가 있다면(너무 많은 종속성, 숨겨진 전역 상태, 부작용) 그것은 디자인 냄새입니다. AI에게 "이 코드를 테스트 가능하게 만들기 위해 어떻게 리팩터링하시겠습니까?"라고 묻는 것은 더 나은 테스트와 더 나은 코드로 이어집니다.
매개변수화된 테스트 및 데이터 다양성
서로 다른 입력으로 동일한 규칙을 확인하기 위해 매번 별도의 테스트를 작성하는 것은 지루하고 유지 관리가 어렵습니다. 매개변수화된 테스트(입력 목록 및 예상 결과에 대해 동일한 테스트 논리를 반복적으로 실행하는 구조)는 이러한 반복을 제거합니다. 단일 테스트 본문에 수십 개의 입력 쌍이 제공됩니다. AI는 수락 규칙을 제공할 때 이러한 입력 예상 결과 테이블을 생성하는 데 매우 효율적입니다. 특히, 한계값과 등가등급을 체계적으로 도표화합니다.
그러나 여기에도 함정이 있습니다. AI는 테스트 중인 코드에서 생성된 테이블의 예상 결과를 도출하는 경향이 있습니다. 이 오류는 매개변수화된 테스트에서 더욱 위험합니다. 하나의 잘못된 논리로 인해 수십 줄이 무효화되기 때문입니다. 따라서 항상 승인 규칙에 따라 예상 결과 열을 독립적으로 계산하고 최소한 몇 개의 행을 수동으로 검증하십시오. 또한 "각 행이 무엇을 나타내는지"에 대한 설명 열을 요청하세요. 따라서 행이 중단되면 어떤 상태가 중단되었는지 즉시 확인할 수 있습니다.
팁: 매개변수화된 테스트 테이블에 의도적으로 "트랩 행"을 추가합니다. 즉, 의도적으로 결과를 잘못 입력하는 것입니다. 테스트를 실행할 때 해당 선이 빨간색으로 바뀌지 않으면 테스트가 실제로 해당 상황을 확인하지 않는 것입니다. 이것은 빠른 모의 합격 확인입니다.
약한 프롬프트 / 강한 프롬프트
약함: "이 함수에 대한 단위 테스트를 작성합니다."
Strong: "taxCalculate(amount, rate) 함수에 대한 [언어/프레임워크] 단위 테스트를 작성합니다. 허용 규칙: 결과 = amount * rate, 소수점 이하 2자리로 반올림됨, 음수 금액 또는 rate는 오류를 발생시킵니다. rate가 0이면 0을 반환합니다. AAA 구조를 사용합니다. 다음 규칙에 따라 예상 값을 수동으로 계산합니다. 함수의 현재 출력을 참조하지 마세요. 커버 바운드 및 음수 사례(0, 음수, 매우 큼, 소수점 이하 자릿수로 반올림). 각 테스트의 이름이 규칙을 설명하도록 합니다. 확인합니다. 외부 종속성 "아니요."
강력한 프롬프트; 이는 수용 규칙, 독립적인 기대값 기대치, 구조 및 엣지 케이스를 제공합니다. 따라서 테스트는 코드의 거울이 아닌 규칙의 수호자가 됩니다.
단위 테스트 품질 표
증상
잘못된 테스트(가짜 신뢰)
좋은 테스트
주장하다
없음 또는 "null이 아님"
기대되는 구체적인 가치
기대값 소스
함수의 출력
수락 규칙 / 수동 계산
중독
실제 DB/네트워크/시간
모의/스텁으로 절연됨
엣지 케이스
오직 행복한 길
한계, 음수, 오류
코드를 깨뜨렸을 때
녹색으로 남아
빨갛게 변하다
이름
테스트1, 테스트메소드
확인하는 규칙을 설명합니다.
복사 가능한 템플릿 4개
1) 규칙 기반 단위 테스트:
귀하의 역할: 수석 소프트웨어 테스트 엔지니어. [언어/프레임워크]: [서명]을 사용하여 다음 함수에 대한 단위 테스트를 작성하십시오. 승인 규칙: [규칙].- AAA 구조를 사용하십시오.- 다음 규칙에 따라 예상 값을 수동으로 계산하십시오. 함수의 현재 출력을 참조하지 마십시오. - 별도의 테스트를 통해 한계, 부정, 오류 및 행복한 경로를 커버합니다. - 각 테스트 이름이 확인하는 규칙을 설명하게 하세요. - 모의 외부 종속성; 실제 논리가 작동하도록 하세요.
2) 돌연변이 저항 제어:
이 단위 테스트를 확인해 보세요. 테스트 중인 코드에 적용할 수 있는 5가지 사소한 조정(+ 대신 a -, > 대신 >=, 경계 이동)을 나열하고 각 테스트에 대해 어떤 테스트가 빨간색으로 바뀔지 알려주세요. 아무것도 반환되지 않으면 테스트가 불충분한 것입니다.코드 + 테스트: [붙여넣기]
3) 테스트 가능성 검토:
이 함수에 대한 단위 테스트를 작성하는 것이 왜 어려운가요? 숨겨진 중독, 글로벌 상태, 부작용, 책임이 많습니까? 테스트 가능하도록 최소한의 리팩토링을 제안합니다. 행동을 바꾸지 마십시오. 코드: [붙여넣기]
4) 불완전한 시나리오 완성:
다음 기능과 사용 가능한 테스트가 제공됩니다. 테스트된 적이 없는 동작/특이 사례(범위 격차)를 나열하고 각각에 대한 테스트를 추가합니다. 기능+테스트: [붙여넣기]
세 개의 미니 케이스
사례 1 - 코드 미러링을 테스트합니다. 개발자는 AI가 반올림 기능에 대한 테스트를 작성하도록 했습니다. 10번의 테스트는 녹색이었습니다. 실제로 함수가 잘못된 방향으로 반올림하고 있었는데 AI가 함수의 출력에서 예상값을 가져왔기 때문에 테스트에서는 오류를 '참'으로 간주했습니다. '규칙 중심' 템플릿을 사용해 기대값을 수동으로 계산하자 4개의 테스트가 빨간색으로 변해 실제 오류가 드러났다.
사례 2 - 돌연변이 제어의 가치. 한 팀은 45개의 단위 테스트에 의존했습니다. "돌연변이 견고성 검사"를 통해 코드에 대한 20가지 사소한 수정을 시도했습니다. 테스트 결과 그 중 11개만 발견되었습니다. 나머지 9번의 중단은 조용히 지나갔습니다. 팀은 약한 테스트를 강화했습니다. 실제 계산 오류는 다음 릴리스의 향상된 테스트에서 발견되었습니다.
사례 3 — 테스트 불가능성은 디자인 냄새입니다. AI는 주문 기능에 대한 테스트를 작성할 수 없으며 지속적으로 실제 데이터베이스가 필요했습니다. "테스트 가능성 검토" 템플릿은 데이터베이스 액세스 기능이 내장되어 있음을 보여줍니다. 종속성 주입이 제거되면 테스트를 작성할 수 있고 코드가 더 깔끔해졌습니다.
일반적인 실수
- 코드에서 예상 값을 도출합니다. AI는 함수 출력을 "올바른" 것으로 받아들입니다. 잘못된 코드를 확인하는 테스트입니다.
- Assert 없이 또는 Trivial Assert를 사용하여 테스트합니다. "그는 오류를 던진 것이 아니라 통과했습니다"라는 논리; 아무것도 확인하지 않습니다.
- 극단적인 조롱. 모든 것을 조롱하고 모의가 반환하는 것만 테스트합니다. 실제 논리는 테스트되지 않습니다.
- 그냥 행복한 길. 한계, 부정 및 오류 상태를 우회합니다.
- 코드를 깨뜨려 테스트하지 않습니다. 돌연변이를 확인하지 않고 녹색을 신뢰합니다.
- 테스트 불가능성을 무시합니다. 열심히 테스트하는 대신 잘못된 디자인을 인식하고 수정하지 않습니다.
요약하면
단위 테스트는 테스트 피라미드에서 가장 빠르고 가장 큰 계층입니다. 가장 저렴한 순간에 실수를 잡아냅니다. AI는 단위 테스트를 생성할 수 있는 능력이 뛰어나지만 가장 큰 함정은 코드 자체에서 예상 값을 도출하여 잘못된 동작을 "올바른" 것으로 가정하는 테스트를 작성하는 것입니다. 해결책: 수용 규칙을 제공하고, 예상 값을 수동으로 계산하고, AAA 및 FIRST 원칙을 시행하고, 외부 세계를 모의하고 실제 논리를 실행하고, 각 테스트를 변형(코드 깨기)으로 테스트합니다. 테스트하기 어려운 코드는 수정이 필요한 디자인 기호입니다.
응용과제
자신의 프로젝트에서 비즈니스 규칙이 포함된 함수를 선택하세요. 승인 규칙을 작성하고 AI가 "규칙 기반 단위 테스트" 템플릿을 사용하여 테스트를 작성하도록 합니다. 예상 값을 수동으로 계산하십시오. 그런 다음 "돌연변이 견고성 검사"를 적용합니다. 코드에서 최소 5번의 작은 중단을 만들고 얼마나 많은 테스트가 빨간색으로 바뀌는지 측정합니다. 발견되지 않은 손상에 대한 새로운 테스트를 추가합니다. 발견된 중단 수(예: 돌연변이 점수)를 보고합니다.
체크리스트
- [ ] 승인 규칙을 제시하고 기대값을 수동으로 계산했습니다.
- [ ] 테스트 결과 코드에서 기대한 값이 도출되지 않았음을 확인했습니다.
- [ ] AAA 및 FIRST 지침에 따라 독립적인 테스트를 확립했습니다.
- [ ] 외부 종속성을 조롱하고 실제 로직을 실행했습니다.
- [ ] 한계, 부정, 오류 사례를 다루었습니다.
- [ ] 코드(변이)를 깨뜨림으로써 테스트가 실제로 보호한다는 것을 증명했습니다.