실용주의 단위 테스트. 14장. 프로젝트에서 테스트.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=195813359

자바와 JUnit을 활용한 실용주의 단위 테스트 by 제프 랭어 / 앤디 헌트 / 데이브 토머스 (지은이) / 유동환

팀동료가 스터디를 14장부터 시작하자고 제안했습니다. 단위 테스트를 팀 문화의 일부로 받아들이기까지 팀원들 간에 일어날 수 있는 논쟁 거리들을 소개하고 있습니다.

빠른 도입

이러니 저러니 해도 우린 모두 일정에 쫓기고 있습니다. 단위 테스트를 작성할 시간이 없다고 말합니다. 하지만 테스트 없이 코드를 만드는 것은 아주 단기간에만 생산적입니다. 

팀과 같은 편 되기

단위 테스트 표준을 정하고 리뷰를 통해 그를 준수하도록 돕습니다. 초창기에 표준화해야하는 목록은 다음과 같습니다.

- 코드를 체크인하기 전에 어떤 테스트를 실행해야 할지 여부

- 테스트 클래스와 메서드의 이름 짓는 방식

- 햄크레스트 혹은 전통적인 단언 사용 여부

- AAA 사용 여부

- 선호하는 목 도구 선택

- 체크인 테스트를 실행할 때 콘솔에 출력을 허용할지 여부

- 단위 테스트 스위트에서 느린 테스트를 분명하게 식별하고 막을 방법

지속적 통합으로 수렴

CI 자체는 요즘 너무 당연해져서, 개인 프로젝트에도 쉽게 적용할 수 있습니다. 다만 통합이 있을 때마다 단위 테스트가 함께 돌아가고 있지 않다면 그 의미가 퇴색됩니다. CI 서버는 나쁜 코드를 용납하지 않도록 건강한 동료 압박을 지원합니다. 

코드 커버리지

높으면 높을 수록 좋겠지만 100%는 불가능합니다. 커버리지 개념은 오로지 속임수를 써야만 100%에 도달할 수 있다는 제한이 내재되어 있습니다. 다만 70% 이상은 되어야 합니다. 코드를 작성하고 습관적으로 단위 테스트를 작성하는 팀들은 비교적 쉽게 70%의 커버리지를 달성합니다. 냉소적으로 볼 때 코드 커버리지는 단지 보기 좋은 숫자에 불과하지만, 목표치를 설정한다거나 추세를 관찰하면서 팀의 분위기를 감지하는데 도움이 됩니다.