본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.
설계가 단위 테스트에 미치는 영향
- TDD를 사용할 때 테스트 코트는 첫 번째 클라이언트가 된다
- 설계 → 인터페이스 작성 → 테스트 코드 작성 → 테스트 코드 수행 → 내부 구현 수정 → 다른 모듈이 사용
- 테스트는 인터페이스 설계에 의존
- 인터페이스 설계 품질이 낮으면 테스트 작성이 어려움
단위 테스트가 설계에 미치는 영향
- 테스트가 있기 때문에 리팩터링 가능
- 두려움 없이 구현 설계를 과감하게 개선
- 리팩터링은 요구사항을 그대로 충족하면서 내부 구현을 수정하는 것
- 단위 테스트가 존재는 요구사항을 충족함을 보장한다
단위 테스트에 의지하는 인터페이스 설계
- 단위 테스트는 낮은 응집에 대한 피드백을 주지 않는다
- 단위 테스트는 일관된 설계를 강요하지 않는다
- 단위 테스트는 의도 노출을 요구하지 않는다
단위 테스트에 의지하는 구현 설계
- 단위 테스트는 책임 분산을 유도하지 않는다
- Mock을 과도하게 사용해버릴 수 있다
- 비공개 운영 코드 테스트
'테스트코드 > 이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법' 카테고리의 다른 글
[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 9장: 인터페이스와 테스트 (0) | 2022.08.11 |
---|---|
[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 8장: 테스트 주도 개발의 한계 (0) | 2022.08.11 |
[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 6장: Should I test private methods (0) | 2022.08.11 |
[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 5장: Mockists vs Classicists (0) | 2022.08.11 |
[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 4장: 테스트 대역 (0) | 2022.08.10 |