[Clean Code 2판] 1-16: Acceptance Testing

1-16장

---

Part1.Code

Chapter16. Acceptance Testing (인수 테스트)

지금까지는 프로그래머가 스스로 통제할 수 있는 영역을 다뤄왔다.

(함수, 클래스, 테스트 코드 등)

하지만, 인수 테스트는 프로그래머의 통제권이 가장 적은 영역이다.

비즈니스 측의 참여가 필수적이기 때문이다.

 

하지만... 안타깝게도 많은 비즈니스 조직이 지금까지 제대로 참여하기를 꺼려왔다.

(ㅠㅠㅠㅠ)

 

시스템이 배포 준비가 됐다는 걸 어떻게 알까?

 

대부분의 조직은 QA 부서에 '승인'을 맡긴다.

QA 팀이 대규모 수동 테스트를 돌려서 시스템이 명세대로 동작하는지 확인하고, 통과하면 배포한다.

 

따라서, 시스템의 진짜 요구사항은 '그 테스트들'이다.

요구사항 문서가 뭐라고 쓰여있든, QA가 테스트를 통과시키면 시스템이 배포된다.

---

The Acceptance Testing Discipline

<모든 요구사항을 테스트로 명세화하라>

 

BA(비즈니스 분석가): 정상 경로(happy path) 시나리오에 집중
QA: 시스템이 실패할 수 있는 수많은 방식을 탐색

 

누가 실행하는가?

실행 책임은 프로그래머에게 있다.

 

No programmer in their right mind wants to manually test the system over and over again. 

제정신인(ㅋㅋ) 프로그래머라면 테스트를 수동으로 하나하나 돌리지 않을 것

당연히 자동화할 것이다.

 

하지만, BA와 QA가 테스트를 작성하기 때문에 자동화 언어는 '그들이 이해하고 작성할 수 있는 언어'여야 한다.

 

이를 위해 만들어진 도구들: FitNesse, JBehave, SpecFlow, Cucumber 등.

 

하지만, 도구가 핵심은 아니다.소프트웨어 동작 명세는 항상 세 요소의 조합으로 이뤄진다.

 

1. 입력 데이터(Arrange/Given)
2. 수행할 행동 (Act/When)
3. 기대 출력 (Assert/Then)

 

15장에서 배운 AAA 패턴과 BDD(행동 주도 개발)의 Given-When-Then 방식이다.

// Given When Then 패턴
Given a page with the wiki text: !1 header
When that page is rendered.
Then the page will contain: <h1>header</h1>

 

인수 테스트 도구를 쓰든, 스프레드 시트로 작성하든, 텍스트 편집기로 작성하든,

이런 형식은 자동화하기 쉽다.

 

15장의 AAA 패턴이 뭔가요? -> 1-15: Clean Tests 참조 https://developer-dreamer.tistory.com/225

---

The Discipline

테스트 작성 이상편:

1. BA: happy path 테스트 작성
2. QA: 실패 시나리오 테스트 작성
3. 테스트는 기능 개발과 같은 시점 혹은 바로 직전에 작성
4. 애자일 스프린트에서는 스프린트 초반에 며칠 테스트 작성
5. 스프린트 끝까지 모든 테스트 통과

 

이 테스트들이 <Definition of Done>이 된다.

기능은 모든 인수 테스트가 통과될 때까지 완성된 것이 아니다.

이걸 다 통과해야 기능이 완성된 것이다.

 

이건 BA와 QA에게 막중한 책임을 부여한다.

이들이 작성하는 테스트가 완전한 기능 명세서이자 전체 시스템의 요구사항 문서이기 때문이다.

 

테스트를 통과시키는 것은 "명세된 기능이 완성되어 동작한다"는 것을 보증한다.

 

테스트 작성 현실편:

BA와 QA가 이런 형식적이고 상세한 문서 작성에 익숙하지 않을 수 있다.

 

중간 목표:

프로그래머가 BA/QA 지도 아래 인수 테스트를 작성한다.

BA/QA가 읽고 승인할 수 있는 수준으로 만든다.

 

궁극적 목표:

BA/QA가 직접 테스트를 작성할 수 있을 만큼 익숙해진다.

(과연)

---

Continuous Build

인수 테스트가 한 번 통과되면?

CI(지속적 빌드) suite에 포함된다.

'이후의 변경이 이미 동작하는 기능을 망가뜨리지 않도록 보장'하기 위해서다.

 

인수 테스트를 CI에 넣는 건

'이 기능은 앞으로도 계속 동작해야 한다'라는 계약을 코드 베이스에 넣는 것이다.

 

CI는 프로그래머가 코드를 체크인할 때마다 자동 실행되는 절차이다.

1. 소스로부터 시스템 빌드
2. 단위 테스트 suite 실행
3. 인수 테스트 suite 실행
4. 결과를 모든 관계자에게 공개

 

지속적 빌드의 상태는 모두가 항상 인지하고 있어야 한다.

 

이전에 통과하던 인수 테스트가 CI에서 실패한다면,

다른 어떤 변경보다 먼저 즉시 수정해야한다.

 

실패가 노이즈가 되면, 진짜 중요한 실패가 생겨도 '아 CI 또 깨졌나봄'하고 넘긴다.

실패를 방치하면, 이 테스트가 언제 왜 깨졌지?를 추적하는게 거의 불가능해진다.

인수 테스트 통과=완료의 정의 라는 공식이 무너진다.

 

지속적 빌드에 실패를 쌓아두는 것은 자멸 행위이다. (ㄷㄷ suicidal이라는 표현을 씀;;)

---

Conclusion

인수 테스트는 21세기 전반기 소프트웨어 개발에서 가장 취약한 부분 중 하나이다.

 

비즈니스와 개발자는 협력하여

BA와 QA가 요구사항을 공식적으로 명세하고

프로그래머가 그 요구사항이 충족되었음을 빠르게 검증할 수 있는 언어와 절차를 만들어 나가야 한다.

 

AI의 등장으로 이 필요성은 두 배로 중요해졌다.

---

비개발자도 쉽게 테스트 모델을 설계하는 툴을 만든 토스 개발자의 강연이 떠올랐다!

함께 보면 좋을 듯 하여 링크 같이 붙여둠

 

비개발자도 ui에서 테스트가 필요한 부분을 클릭해서 테스트 시나리오를 만들 수 있게 한 것임

원래 개발자가 테스트 코드를 직접 짜면서 생기는 병목을 해결한 것

 

그리고, 이 툴을 만들 때 접근성 태그를 많이 사용하면서 자연스럽게 접근성(aria-label)도 개선이 됐다고 함

 

https://youtu.be/QUhjuz3NogA?si=JGdgWG5o2HMNw6R6&t=625

 

작성: 2026.03.06. 01:04