유닛 테스트 책을 읽고

 

좋은 테스트란 무엇일까?
우아한테크코스에 있던 "A군"의 말이 생각난다...

"최근 구조 하나를 바꿨어. 신규 기능을 하나 추가할 때마다, 코드가 n제곱씩 늘어나더라고?
그래서 각이다 싶어 상태패턴을 도입했지... 그랬더니 테스트가 60개 깨지네?"

무언가가 잘못됐다고 생각했다...
이 불편함의 근원에 대해 성실하게 조사해봤었어야 했는데 당시에는 무척 바빠서 그러지 못했다
그로부터 1년 가까이 지난 후 시간이 있을 때마다 테스트에 관한 책을 조금씩 읽어봤다

 

 

 

저자가 수학이란 학문을 좋아하는 것 같다

책에서 그런 느낌을 물씬 받았다

어떤 공리와 비슷한 것들을 정의해 놓고 그 위에 이론과 생각을 차곡차곡 쌓아나간다...

 

다행히 이론적이기만 한 책이 아니라 실용적인 관점에서 접근한 책이다

이게 가장 중요하다고 생각한다 "실용적"

 

 

 

 

인상 깊었던 내용들

테스트는 항상 최대한의 이득을 얻도록 노력해야 한다고 한다

"테스트에 드는 노력은 가능한 줄이고 이에 대한 이득을 최대한 늘려야 한다"

 

[ 01 Unit Test 목표 ]

테스트가 없을 경우 처음에는 빠르게 작업할 수 있지만,

시간이 흐름에 따라 빠르게 작업 소요시간이 늘어난다

이를 software entropy라 한다

테스트가 있으면 선형적으로 풀어나갈 수 있다

 

모든 테스트를 작성할 필요는 없다

잘못된 경고를 발생하거나 양만 많은 테스트는 유지보수에 어려움을 준다

코드는 자산이 아니라 책임이다

코드가 더 많아질 수록 SW내 잠재적인 버그에 노출되는 표면적이 넓어진다

테스트 또한 역시 코드다

 

 

 

[ 02 Unit Test의 정의 ]

고전적 접근법 == 디트로이트 == Classist 접근법

런던 스타일 == mockist

 

개인적으로 고전적 스타일을 선호한다

 

 

 

[ 03 Unit Test의 구조 ]

"클래스_시나리오_예상결과"

"User_createUser_return_1"

이런 건 도움이 되지 않는다

 

일반인들에게 시나리오를 설명하는 것처럼 테스트 이름을 짓도록 하자

"OrderLine_with_one_more_item_is_invalid()"

 

 

 

[ 04 좋은 Unit Test의 4대 요소 ]

- 회귀 방지:  버그 방지

- 리펙터링 내성:  리펙터링할 때 테스트가 깨지는가

- 빠른 피드백:  테스트 코드 실행 속도

- 유지 보수성

 

거짓 양성(false positive):

허위 경보, 사실 production의 기능은 잘 동작하지만 테스트에서만 red가 뜨는 현상

리펙터링 내성 지표의 하나다

테스트에 구현 세부사항이 많이 결합돼 있으면 이런 현상이 일어나기도 한다

 

거짓 음성(false negative):

프로덕션에서는 실제로 문제가 잇는데, 테스트에서는 green이 뜨는 현상

회귀(버그) 방지에 좋지 않다

 

 

 

[ 05 목과 테스트 취약성 ]

테스트 대역: 테스트르 편리하게 하는 것, 목과 스텁이 있음

tool의 목(Mocking Library)와 대역의 목은 다르다

도구의 목은 대역의 목, 스텁 역할을 두가지 다 가능하다

 

런던파를 따라 무분별하게 목을 사용하면 구현 세부 사항에 결합돼 리펙터링 내성에 취약하게 된다

리펙터링 내성은 보통의 경우 두 가지 중 하나다, 있거나 없거나... 

 

 

 

[ 06 Unit Test 스타일 ]

리펙터링 내성 지표에 따른 스타일 비교

- 출력 기반 테스트:  거짓 양성 방지 가장 우수

- 상태 기반 테스트

- 통신 기반 테스트

 

 

 

[ 07 가치 있는 단위 테스트를 위한 리펙터링 ]

... (생략) ...

 

 

 

[ 08 통합 테스트 ]

Integration Test: 테스트의 품질이 가장 높다

 

YAGNI (You Aren't Need It의 약자: 현재 필요하지 않은 기능에 시간을 들이지 말라)

진정한 추상화는 발견하는 것이지, 발명하는 게 아니다. 미리부터 인터페이스를 작성하지 말자. 인터페이스가 진정으로 추상화되려면 구현이 적어도 두 가지는 있어야 한다

 

 

 

[ 09 목 처리에 대한 모범 사례 ]

... (생략) ...

 

 

 

[ 10 데이터베이스 테스트 ]

... (생략) ...

 

 

 

[ 11 Unit Test 안티 패턴 ]

... (생략) ...