우리 꿈은 TDD! 우리의 꿈은 TDD!
내 꿈은 TDD+ 기능테스트 프로젝트를 해보는 것이다
흑흑 오랜 내 꿈을 드디어 이룰때가 왔다
https://www.youtube.com/watch?v=3LMmPXoGI9Q
TDD 사용이유: 1. 리팩토링이 편하기
2. 디버깅 시간을 줄여준다
3. 동작하는 문서 역할을 한다
- 자연스레 테스트 커버리지가 높아진다 테스트 커버리지가 뭘까?
- 오버 엔지니어링 방지
- 설계에 대한 피드백이 빠르다
TDD의 오해
- TDD는 설계방법론이다?
- TDD는 높은 응집을 유도하지 않는다
- TDD는 단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다
- TDD는 인터페이스 일관성을 도출하지 않는다
- TDD의 리팩토링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다
TDD를 실패하는 사람이 하는 테스트
1. 코드가 이루고자 하는 가치나 기능을 테스트하기 보다 그 기능을 어떻게 구현하고 있는지를 테스트한다
2. 결국 테스트 케이스들이 구현체와 결합도가 높아진다
3. 구현체들을 리팩토링하면 결합되어 있는 테스트 케이스들이 모두 깨져버린다
구현체가 아닌 인터페이스를 테스트해야한다.
이제 본격적으로 단위테스트에 대해 알아보자
아마 정처기에서 다들 단통시인으로 많이 외웠을.. 테스트 종류이다
단위 테스트
1. 가장 작은 단위의 테스트
2. 일반적으로 메서드 레벨
3. 검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 또는 프로세스
4. Unit Testing은 테스트코드가 목적 코드의 완전성을 입증해주기 때문에, 테스트 코드 그 자체만으로 주요한 가치가 있음
좋은 단위테스트를 만들기 위한 FIRST법칙
-
빠르게
테스트가 느리면 자주 돌릴 엄두를 못 내겠죠? -
독립적으로
테스트는 서로 의존해선 안된다 하나가 실패하면 나머지도 잇따라 실패하게 된다 -
반복 가능하게
테스트는 어떤 환경에서도 반복 가능해야한다
실제, QA, 네트워크가 연결되어 있지 않은 경우 모두 돌아가야한다 -
자가검증
테스트는 boolean값으로 결과를 내야만 한다. -
적시에
테스트는 항상 적시, 그러니까 실제 코드를 구현하기 직전에 구현해야 한다.
