[ TDD ] [책] 테스트 코드 작성 순서

앞번의 암호 강도 측정기능의 테스트 예시 에서 보면,

테스트 코드를 작성한 순서는 다음과 같다.

1. 모든 규칙을 충족하는 경우
2. 길이만 8글자 미만이고 나머지 조건은 충족하는 경우
3. 숫자를 포함하지 않고 나머지 조건은 충족하는 경우
4. 값이 없는 경우
5. 대문자를 포함하지 않고 나머지 조건을 충족하는 경우
6. 길이가 8글자 이상인 규칙만 충족하는 경우
7. 숫자 포함 조건만 충족하는 경우
8. 대문자 포함 조건만 충족하는 경우
9. 아무 조건도 충족하지 않는 경우

위의 순서는 다음 규칙을 따른 것이다.

• 쉬운 경우 → 어려운 경우
• 예외적인 경우 → 정상적인 경우

초반에 복잡한(어려운) 테스트부터 시작하면 안 되는 이유

만약에 테스트 코드 작성 순서를 다음과 같이 진행했다고 하자. 

1. 대문자 포함 조건만 충족하는 경우
2. 모든 규칙을 충족하는 경우
3. 숫자를 포함하지 않고 나머지 규칙은 충족하는경우

이렇게 진행하다보면 첫 번째 테스트는 쉽게 넘어가지만, 두 번째는 모든 규칙을 검증하는 코드를 구현해야 할것 같은 느낌이 든다.

 

한번에 완벽한 코드를 만들다 보면

▶ 나도 모르게 버그를 만든다.

    → 버그를 잡는데 많은 시간을 허비한다.

    → 테스트 통과 시간도 길어진다

→ 집중력이 떨어진다

 

구현하기 쉬운 테스트부터 시작하기

암호 강도 측정기능의 테스트 를 한다고 하면 가장 쉬워보이는 것은 다음과 같다.

• 모든 조건을 충족하는 경우
• 모든 조건을 충족하지 않는 경우

두 가지 경우다 그냥 단순히 해당 값을 리턴하면 되기 때문이다.

• 모든 조건을 충족하는 경우  → return STRONG
• 모든 조건을 충족하지 않는 경우 → return WEEK

먼저 "모든 조건을 충족하는 경우"  부터 시작했다고 하면, 다음으로 생각해 볼수 있는 테스트는 다음과 같다.

• 모든 조건을 충족하지 않는 경우 → 모든 조건을 검증하는 코드 필요
• 한 가지 조건만 충족하는 경우 → 한 가지 규칙을 충족하는지 검증하는 코드 필요
• 두 가지 조건을 충족하는 경우 → 두 가지 규칙을 충족하는지 검증하는 코드 필요

이렇게 보면 "한 가지 조건만 충족하는 경우" 가 더 구현하기 쉽다.

 

이런 식으로 한 가지 테스트를 통과했으면 그 다음으로 구현하기 쉬운 테스트를 선택하여 진행해야 한다.

 

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

초기 설계 단계에서 예외 처리를 고려하는 것은 프로그래밍의 중요한 부분

 

예외 처리를 무시하고 코드를 작성할 경우,

→ 나중에 예외 상황을 반영하기 위해 코드 전체를 개편해야 할 수도 있음

→ 복잡한 조건문을 추가 해야 할 수도 있음

→ 코드의 복잡성을 증가시키고 버그 발생 가능성 상승

 

완급 조절

한번에 얼마만큼의 코드를 작성할 것인가?

1. 정해진 값을 리턴
2. 값 비교를 이용해서 정해진 값을 리턴
3. 다양한 테스트를 추가하면서 구현을 일반화

뻔한 구현이라도 위 단계를 거쳐서 연습을 하면,

구현이 막막해도 조금씩 기능을 구현해 나갈 수 있다.

 

리팩토링?  ▶  코드의 가독성 향상

코드 중복 발생, 코드가 길어진다

▶ 메서드 추출과 같은 기법을 이용하여 리팩토링  

▶ 메서드 이름으로 코드의 의미 표현

 

팁

 

리팩토링

1. 동작하는 코드를 먼저 작성

2. 변경하기 쉬운구조로 코드를 구성

3. 필요한 부분은 리팩토링

4. 메서드의 구조에 영향을 주는 리팩토링은 큰 틀에서 구현 흐름이 눈에 들어오기 시작한 뒤에 진행 (코드의 의미와 구조가 명확해지만 리팩토링 진행)

5. 범위가 큰 리팩토링은 시간이 오래 걸리므로 먼저 테스트를 통과 시키는데 집중

 

테스트

1. 테스트할 목록을 미리 정하기

2. 정한 테스트 목록중 구현이 쉽고 예외적인지 예측

3. 새로운 테스트 사례는 바로 목록에 기록

4. 목록을 하나씩 통과하면서 진행한다.

 

구현이 막막할때

1. 검증하는 코드부터 작성해 본다.

 

구현이 막힐때

1. 과감하게 지우고 다시 시작해보자