TDD를 적용한 문제 해결(feat. makerjun)

1주차 세션에서 jun이 TDD를 7단계로 체화하는 방법에 대해 세션을 진행하였다. 우선, 아래의 방식을 최대한 따라하며 나만의 방법을 정립해 나아가야겠다. 😉

1단계

전체 문제가 해결되었을 때 어떤 상태일지 상상해보기. 결국 내가 뭐하려는 걸까?

• 1단계 기능명세서 TC 작성
• 1단계 TC All Pass
• 1단계 코드 리팩터링
• 과제를 하면서 신경쓴 부분 정리하기

---

2단계

적당한 난이도로 문제를 쪼개거나 변형하기. 단, 핵심을 포함하게

1. 경주 셋팅
- 자동차 이름(참여자)를 입력 받는다.

2. 경주 진행
- 전진 조건을 정하고,
- 랜덤으로 차를 전진시키고,
- 경주를 하고,
- 각 자동차별 진행 결과 출력

3. 우승자 출력
- 우승자를 출력하고, 여러명인 경우 ,를 이용하여 보여준다.
- 참고로 우승자는 제일 멀리 간 사람이다.

• 2단계 기능명세서 작성
• 2단계 기능명세서 TC 작성
• 2단계 TC All Pass
• 2단계 코드 리팩터링
• 과제를 하면서 신경쓴 부분 정리하기

---

3단계

핵심과 가까우면서, 지금 내 상태에서 비교적 쉽게 할 수 있는 적절한 것을 하나 선택한다.
이걸 먼저 동작되게 함으로써 뒤에 구현할 기능들이 수월해지는가.
이걸 먼저 하기 때문에 1번에 가까워지거나, 1번을 구현하는데 있어 내가 더 유리해지는가

• 3단계 기능명세서 작성
• 3단계 기능명세서 TC 작성
• 3단계 TC All Pass
• 3단계 코드 리팩터링
• 과제를 하면서 신경쓴 부분 정리하기

---

4단계

결과의 모습이 뭔지 구체화하고 시뮬레이션한다.

자동차 입력 받기, 
자동차 이름을 입력 받는 그 인터렉션에서 어떤 상황들이 있을 수 있을지, 예외케이스를 포함해서!

- 빈값인 상태에서 엔터를 치는 경우
- 자동차를 너무 많이 입력하는 경우
- 같은 자동차 이름을 입력하는 경우도 있을수 있고
- 특수문자를 넣은경우도 있을 수 있고
- 가나,다라,,,마라
- 너무 긴 이름의 자동차 이름을 입력한 경우도 있을 수 있고

• 4단계 기능명세서 작성
• 4단계 기능명세서 TC 작성
• 4단계 TC All Pass
• 4단계 코드 리팩터링
• 과제를 하면서 신경쓴 부분 정리하기

---

5단계

우리가 일반적으로 보는 TDD 사이클이 여기서 진행된다

1. 실패하는 테스트 코드를 작성한다. (빈값인 상태에서 엔터를 치는 경우, 프로그램이 종료된다)
2. 테스트를 통과할 만큼의 개발 코드를 작성
3. 리팩터링

jest라는 도구를 이용해서 진행을 할껀데, 계산기 온보딩 미션에서 기본적인 연습을 해보셨다면 좀 더 수월하게 진행하실 수 있을 거고

• 5단계 기능명세서 작성
• 5단계 기능명세서 TC 작성
• 5단계 TC All Pass
• 5단계 코드 리팩터링
• 과제를 하면서 신경쓴 부분이나 리뷰 남길 부분 정리하기 없다면 패스

---

6단계

리팩터링을 하면서 중복을 줄이거나 의도를 드러나게 한다.

• 6단계 기능명세서 작성
• 전체 리팩터링 진행 (객체는 객체답게 사용했는가? 관심사별로 도메인을 잘 분리했는가? 객체로 쓸 것인가 )
• 세부 리팩터링 진행 (가독성, 로직, 하드코딩 값 점검 등)

---

7단계

리팩터링하고 나서는 기존의 테스트 코드가 잘 동작하는지 확인한다

• 테스트 코드를 실행한다.
• 동작하지 않는 경우 리팩터링 과정에서 발생한 사이드이펙트를 확인하고 수정한다.
• 동작하는 경우 1, 2번으로 돌아가서 새로운 문제를 해결한다.

---

테스트 코드 작성. 언제?

1. 테스트를 가장 먼저 작성한다. 만족하는 코드가 없는 상태이므로 테스트는 실패함
2. 테스트를 통과하는 코드를 작성한다.
3. 리팩터링: 중복이 보이거나 더 개선할 방법이 있다면 코드를 개선한다.

3대 원칙 - 로버트 C. 마틴 (밥 아저씨, 클린 코더)

1. 실패할 테스트를 작성하기 전에는 아무런 프로덕션 코드도 작성하지 않는다.
2. 실패할 테스트 말고는 작성하지 않는다.
3. 현재 실패한 테스트를 만족시키는 코드 외에는 작성하지 않는다.

좋은 테스트의 조건

1. 실행 속도가 빨라야 함.
2. 내부 구현(테스트하지 않는 부분)을 변경했다고 해서 테스트가 실패하면 안된다. 인터페이스(입출력 위주)를 중심으로 작성.
3. 버그를 찾을 수 있어야 한다. 만들었다고 끝이 아님 테스트 시나리오를 잘 설정해야 함.
4. 테스트 결과에 일관성이 있어야 한다. 코드가 변하지 않았다면 테스트 결과는 항상 동일 해야 한다.
5. 의도가 명확히 드러나야 한다.