TDD 테스트 코드 작성 방법

1. 순서 정하기

1) 쉬운 경우에서 어려운 경우로 진행

2) 예외적인 경우에서 정상인 경우로 진행

 

*암호 검사기 연습 예제 순서를 보면 쉬운 경우에서 어려운 경우로 진행 됨

1. 모든 규칙 충족: 단순 값(Ex. 상수)을 리턴값으로 넣어서 테스트 -> 새로운 추가 테스트 넣어서 에러 발생 시 -> 상수 제거 후 일반화

2. 1번 규칙 미충족, 나머지 규칙 충족

3. 2번 규칙 미충족, 나머지 규칙 충족

4. 3번 규칙 미충족, 나머지 규칙 충족

5. Null이거나 값이 없는 문자열 -> 유효하지 않은 값

6. 1번 규칙 충족, 나머지 규칙 미충족

7. 2번 규칙 충족, 나머지 규칙 미충족

8. 3번 규칙 충족, 나머지 규칙 미충족

9. 모든 규칙 미충족

 

 

2. 예외 상황을 먼저 테스트 해야하는 이유

- 다양한 예외 상황은 복잡한 if-els블록을 동반할 때가 많음

- 나중에 발견된 예외를 반영하려면 코드의 구조를 뒤집거나, 조건문을 중복해서 추가하는 상황 발생 -> 코드가 복잡해지면 버그 발생 가능성을 높임

 

3. 얼마만큼의 코드를 작성할 것인가?

TDD를 처음 접할 시 아래 단계에 따라 익히는 연습하기

1. 정해진 값 리턴

2. 값 비교를 이용해서 정해진 값 리턴 <- 새로운 경우의 값을 넣어 테스트 해보기

3. 다양한 테스트를 추가하면서 구현 일반화

 

4. 지속적인 리팩토링

1) 언제?

- 테스트 통과 후 리팩토링 진행

 

- 테스트 대상 코드의 리팩토링 구체적인 시점

• 상수를 변수로 변경했을 때, 변수명을 변경했을 때 -> 작은 것은 발견 시 바로 실행
• 메소드 추출과 같은 메소드 구조에 영향을 주는 것 -> 큰 틀에서 구현 흐름이 눈에 들어오기 시작한 뒤에 진행

*주의사항

- 구현 초기에는 전반적인 흐름을 몰라서 메소드 추출과 같은 리팩토링 진행 시 코드 구조를 잘못 잡을 가능성이 높고, 코드가 잘못되면 다음 테스트 통과 과정에서 코드가 복잡해지거나 어려워질 수 있음

 

- 리팩토링 후 문제가 있다고 판단되면 즉시 리팩토링을 취소해서 코드를 원상 복구 후에 진행하고 그 후에 코드 의미나 구조가 명확해질 때 다시 리팩토링 시도

 

 

2) 무엇?

- 코드 중복은 대표적인 리팩토링 대상

- 코드가 길어지면 메소드를 추출하고 메소드명으로 코드의 의미를 표현하자

 

 

3) 왜?

- 지속적인 리팩토링은 코드 가독성이 높아짐 -> 코드 분석이 쉬워짐, 수정 요청이 있을 시 파악 및 변경이 쉬움 -> 유지보수에 좋음

 

 

 

참고: 최범준의 테스트 주도 개발 시작하기