Part III 프로세스
CHAPTER 11 테스트 개요
테스트는 처음부터 프로그래밍과 함께다
소프트웨어와 시스템 복잡도에 대응하기 위해 테스트 방식을 극적으로 진화
그 진화의 중심에는 개발자가 주도하는 테스트와 자동 테스트가 있다
자동 테스트는 버그가 몰래 숨어들어 고객을 놀라게 하는 사태를 막아준다
테스트 체계가 잘 갖춰져 있다면 변화를 두려워할 이유가 없다
시스템을 더 많이 더 빠르게 변경하고 싶다면 더 빠르게 테스트 하는 방법을 모색해야 한다
테스트를 작성하는 행위가 시스템 설계에도 영향을 준다
테스트를 작성하는 이유
- 테스트 하려는 단하나의 행위
- 특정한 입력
- 관측 가능한 출력 혹은 동작
- 통제된 조건
테스트는 엔지니어에게 신뢰를 줄때만 가치가 있다.
최고의 팀은 팀원들의 집단 지성을 팀 전체의 이익으로 환원하는 방법을 찾아내야 된다
테스트 코드가 주는 혜택
- 디버깅 감소
- 자신 있게 변경
- 더 나은 문서자료
- 더 단순한 리뷰
- 사려 깊은 설계
- 고품질의 릴리스를 빠르게
테스트 스위트 설계하기
- 테스트의 크기
- 작은 테스트
- 제약이 가장심하다
- 중간 크기의 테스트
- 단 한 대의 기기에서 수행
- 큰 테스트
- 여러 대의 기기를 활용
- 테스트 크기와 무관한 공통 습성
- 테스트는 독립적이어야 한다(밀폐 되어야 한다)
- 작은 테스트
- 테스트 범위
- 좁은 범위 테스트
- 중간 범위 테스트
- 넓은 범위 테스트
- 안티 패턴
- 아이스크림 콘
- 종단간 테스트를 많이 작성하고 통합테스트나 단위 테스트는
- 모레시계
- 종단간 테스트와 단위테스트는 많지만 통합테스트가 적다
- 아이스크림 콘
- 비욘세 규칙
- 네가 좋아했다면 테스트를 준비했어야지
- 코드 커버리지
구글 규모의 테스트
구글은 모든 코드를 모노리포로 관리
리포지토리 브랜치를 사용하는 팀은 거의 없다
테스트 비용을 낮추는데 투자하지 않으면 종국에는 엔지니어들이 테스트가 전혀 가치가 없다고 결론 낼 것이다
구글의 테스트 역사
- 오리엔테이션 수업
- 테스트 인증
- 화장실에서도 테스트
- 화장실 변기 않에 붙히기
- 오늘날의 테스트 문화