구글 엔지니어는 이렇게 일한다 #12장 단위테스트를 읽고

#12 단위 테스트

| 일부 내용
첫째, 버그도 없고 자신의 검증 대상과 관련 없는 변경 때문에 실패하는 '깨지기 쉬운' 테스트들이 도사리고 있었습니다. 둘째, 무엇이 잘못되어 실패했는지, 어떻게 고쳐야 하는지를 파악하기 어려운 '불명확한' 테스트들이었습니다. 애초에 무슨 기능을 어떻게 검사하려고 했는지조차 이해하기 쉽지 않았습니다.

 

책에서는 '깨지기 쉬운 테스트' 와 '불명확한 테스트' 를 예시로 맹목적인 테스트로 인해 발생 할 수 있는 생산성 저하 케이스에 대해 설명해주고 있다. 실제 개발을 진행하며 이런 상황을 빈번히 마주치게 된다. 그럴때마다 어떤것이 올바른 테스트 작성 방향성인지 헷갈릴 경우가 많다. 지금도 일부분에 대해서는 혼동이 오고는 한다. 이건 좀 더 경험 / 역량이 쌓이면 해결될것이라고 생각한다.

 

---

 

| 일부 내용
테스트의 추상화 수준이 적절하지 않다는뜻입니다. 
------
단위의 범위를 잘 정해서 어디까지가 공개 API 인가를 정하는 일에 과학적인 정답은 없습니다. 
------
또한 테스트를 더 명확하게 만들 수 있다면 DRY (Don't Repeat Yourself) 원칙을 거스르는 게 나을 떄도 많습니다.

 

테스트 작성에 대한 적절한 선을 찾는것이 아직은 모호하게 느껴진다.

 

---

 

| 일부 내용
Cucumber 와 Spork 처럼 given/when/then 을 직접 지원하는 테스트 프레임워크까지 생겨났습니다.

 

실제 given/when/then 을 사용하게 되면 테스트 코드 작성이 명확해지고, 추가적인 주석 작성을 통해 코드 뿐만 아니라 실행 흐름을 파악하는데 도움이 되었다.

 

하나의 테스트 케이스를 작성하는 과정에서 when/then 이 교차되며 테스트 케이스의 크기가 비대해지는것을 주의해야 한다.

책에서는 블록이 하나씩이면 충분하다고 안내되어 있다. 나도 이에 동의한다.

 

---

 

| 일부 내용
DRY 를 고집하는 대신 테스트 코드는 DAMP 가 되도록 노력해야 합니다. DAMP는 '서술적이고 의미 있는 문구' 를 뜻합니다. 단순하고 명료하게만 만들어준다면 테스트에서 다소의 중복은 괜찮습니다.
------
DAMP 가 DRY 를 대체하지는 않습니다. 보완해주는 개념 입니다.

 

DAMP 라는 새로운 개념도 신기했지만, DRY 를 신봉하지 말고 DAMP 를 보완제로 사용한다는것도 신기했다. 

실제로 책에서 JAVA 코드를 예제로 설명해주었을때, 테스트 코드의 가독성이 많이 향상되는것을 눈으로 확인 할 수 있었다.