- 단기간에 이득을 얻으려고 품질을 떨어뜨리는 선택에 대해서는 대가가 따른다.
- 테스트 없이 코드를 만드는 것은 매우 단기간에만 생산적이다.
- 코드를 체크인하기 전에 어떤 테스트를 실행해야 할지 여부
- 테스트 클래스와 메서드의 이름 짓는 방식
- 햄크레스트 혹은 전통적인 단언 사용 여부
- AAA 사용 여부
- 선호하는 목 도구 선택
- 체크인 테스트를 실행할 때 콘솔에 출력을 허용할지 여부
- 단위 테스트 스위트에서 느린 테스트를 분명하게 식별하고 막을 방법
- 리뷰 세션을 통해 단위 테스트 작성자가 다른 팀원들에게 피드백 요청
- 페이건 검사 같은 기법을 사용하여 리뷰 절차 공식화
- 풀 리퀘스트 ( gitHub )
- 코드 리뷰 플러그인 ( IDE )
- 많은 논란의 주제
- 사후 리뷰는 현실적으로 많은 회사에 시간적 여유가 없으므로 결과적으로 리뷰는 바라는 것보다 더 적은 결함을 찾게됨 ( 이미 동작한다고 알려진 코드를 되돌리거나 심각하게 재작업하는 것은 부담 )
- 짝 프로그래밍은 두번째 사람의 눈으로 시작부터 품질이 좋은 코드르 만들수 있다는 희망을 줄수있음.
- CI는 코드를 더 자주 통합하고 그 결과를 매번 검증하는 것을 의미함.
- CI의 실천은 지속적 통합 서버라고 하는 도구의 지원을 받음 ( 소스 저장소 모니터링 )
- CI 서버가 어떤 가치를 제공하려면 빌드가 단위 테스트를 함께 수행해야함.
- 서로 다른 도구는 측정방식이 다르다
- 엠마 - 코드의 기본 블록 방식을 사용
- 코버투 - 코드의 줄 수로 측정
- 커버리지 개념은 오로지 속임수를 써야만 100%에 도달할수 있다.
- 인자 없는 생성자는 테스트 코드에서 직접 호출하지 않기 때문에 코드 커버리지에 포함 X
- 비교적 쉽게 코드 커버리지 70% 달성 ( 30%는 보통 나쁜 의존성 때문에 그 코드가 어렵거나 테스트 하기 어려우나, 코드 결함의 30%는 이러한 테스트 되지 않은 코드에 있음 )
{% hint style="info" %} 제프의 코드커버리지 이론 : 낮은 커버리지의 영역에서 나쁜 코드의 양도 증가한다. {% endhint %}
커버리지 퍼센트 자체는 오도될 수 있음 - 커버리지 도구는 단일 단언을 사용했는지 여부를 신경 쓰지 않음.
이해하고 유지 보수 하기 어려운 가치있는 단언을 포함하지 않은 나쁜 테스트를 작성할수도 있음.
테스트 작성을 완료했다고 생각할 때 커버리지 도구를 실행할것!
커버하지 않은 코드 영역을 염려한다면 더 많은 테스트를 작성할것!
코드 커버리지 숫자는 그 자체로 큰 의미가 없으나, 코드 커버리지의 추세는 중요함!