TDD 챌린지 1일 차

💜 TDD 챌린지 1일 차

TDD 챌린지 1일차~👏 동준님의 TDD OT를 듣고 정리해보았다.

 

TDD는 실패하는 테스트를 먼저 만들고, 그 테스트를 통과하기 위해 코드를 짜는 개발 방법이다.

TDD를 하는 '사고 방식'이 중요하다. 내가 만든 무언가가 제대로 동작하는지 빠른 피드백을 받기 위한 사고방식이기 때문이다.

 

훌륭한 엔지니어의 역량은 무엇일까?

1. 좋은 코드 작성

2. 작업의 현재 가치 극대화: 적은 코드로 더 의미있게

3. 데이터에 기반한 의사결정

4. 동료의 효과적인 의사결정 돕기

5. 꾸준한 학습

---

현실 세계에서의 피드백의 필요성

내가 던진 농구공이 골대에 들어갔는지 만약 1시간 뒤에 알 수 있다면?

- (골대에 들어간 경우) 공을 어떻게 넣었었는지 감을 잡기 어렵다.

 

양치는 20년 넘게 닦아도 치과에서 매번 혼난다.

- 양치질에 대한 정확한 피드백은 치과에 방문할 때(대개 1~2년에 방문하기 때문) 받아볼 수 있기 때문이다.

- 치면 착색제를 도포하고 양치를 하면 시각적(즉각적)으로 피드백 받을 수 있어서 양치를 잘 할 수 있게 된다.

 

공항에 보안 검색대. 예전에는 검색 요원 전문성이 1년 일한 사람과 5년 일한 사람의 차이가 별로 없었다.

- 테러나 큰 사건이 일어나지 않는 이상은 놓친 부분에 대한 피드백을 받기 어려웠기 때문인데,

짐이 지나갈 때 가짜 레이어를 덧씌워서 애매한 화기나 날카로운 물건 등이 있을 경우의 상황을 만들어 확인한다면, 평소에 뭘 놓치는지 피드백을 받기 쉽다는 것이다.

---

 

TDD는 내 결정이 잘 동작하는지 빠르게 자주, 꾸준하게 피드백을 얻기 위한 사고 방식

테스트 코드는 의도치 않은 유용한 부산물인데 피드백을 위해 작성한 코드가 미래의 나, 동료들에게 어떤 시퀀스로 시스템을 만들었는지 맥락을 볼 수 있고, 그 다음 기능을 만드는데 도움이 된다.

 

TDD의 핵심은 피드백이다.

문제를 잘 해결할 수 있게 더 자주, 더 빨리, 더 꾸준히 피드백을 받자.

테스트 코드가 없더라도 피드백을 받을 수 있도록 문제를 쪼개고 해결해 나가면 이또한 TDD적 문제를 해결해가는 방법이 된다.

---

TDD적으로 피드백을 더 자주, 더 꾸준히 받는 방법

사고방식 1: 동작 가능한 가장 작은 버전부터 만들기 (핵심을 포함하라)

 

예를 들어, 계산기 애플리케이션을 만드는 것을 생각해보자.

중요한 핵심 기능은 '계산 기능'일 것이다.

동작 가능한 가장 작은 버전으로 쪼갤 수 있어야한다.

 

계산이 동작하려면 최소한의 조건이 2개의 숫자일 것인데

첫 번째 숫자, 두번째 숫자, 그리고 연산이 있을 것이다.

 

전체의 동작을 고민하기보다 동작 가능한 작은 버전부터 고려해보자.

2개의 숫자를 다루는 계산기를 만든다고 하면 더 빠르게 핵심 기능을 만드는 데 가까워 질 수 있다.

최소한의 코드만 작성해보는 것이 TDD 적으로 빠른 피드백을 받기 위한 과정이 된다.

 

1. UI 없이 사칙연산이 되는 것만 먼저 빠르게 만들기

덧셈, 뺄셈, 곱셈, 나눗셈. 최소한의 학습으로 계산기의 핵심을 구현할 수 있다.

핵심 기능이 동작한다면 그 다음 단계로 확장해나가자.

 

2. UI없이 동작이 되는 것을 확인했다면, 최소한의 UI로 동작이 되는지 확인해보자.

최소한의 이벤트와 간단한 UI로 2개의 숫자가 잘 동작하는지 확인을 해보자.

 

3. 잘 동작한다면 버튼 UI를 추가하고, 더 복잡한 이벤트를 처리하는 방법으로 확장하자.

4. UI 레이아웃 잡기

5. 스타일 입히기

 

위 5개의 과정에서 가장 중요한 것은 항상 동작해야한다.

동작 가능한 작은 기능은 '내가 구현하려고 하는 가장 핵심 기능'이 무엇인지 찾자.

핵심 기능이 동작하기 위한 가장 작은 버전을 만든다면 무엇일까?에 대한 질문을 던지고 만드는 연습을 하자.

 

 

 

✅ 단순하면서 진짜 사용자가 있는 것을 만들자
✅ 작고 유용한 것을 매일 만들어라

 

 

사고방식 2. Known to unknown

아는 것에서부터 모르는 영역으로

 

사용자가 계산기 앱에서 최종적으로 얻고자 하는 것은 '계산 결과' 일 것이다.

그렇다면, UI적인 부분도 계산 결과를 중심으로 테스트 코드를 짜볼 수 있을 것이다.

모든 테스트 코드를 다 짤 수는 없으므로 핵심 기능 중심으로 작성한다. 피드백이 필요한 만큼만!

---

TODO: 고민해 볼 것

- 만들고 싶은 앱과 해당 앱의 핵심 기능을 정의하여 테스트 명세 작성해보기

사용자가 있는 앱을 고려해보자. 뭘 만들지 🙄