🏹 원정대란?
팀 프로젝트나 단순 스터디가 아니라, 각자가 송곳 같은 강점 1개를 만들기 위해 동료와 함께 지식을 탐험하는 우아한 테크코스 프론트엔드만의 활동이에요.
해당 활동은 총 4명이서 약 2주간 진행했어요.
TDD를 선택한 이유
로또 미션을 진행하면서 페어 프로그래밍으로 TDD를 진행해 봤지만 지금 내가 하고 있는 것이 TDD가 맞는지, 올바른 방향으로 나아가고 있는건지 확신을 얻을 수가 없었어요.
기준이 하나도 없었기 때문에 TDD를 실천하는 나만의 기준을 하나 만들고 싶었어요.
🚗 쉬운 문제부터 TDD 적용해보기 (1차 실패)
처음으로 시도했던 것은 프리코스 때 진행했던 자동차 경주를 각자 TDD로 해결해 보는 것이었어요.
이전에 TDD를 했을 때와는 다른 시도를 해봤습니다.
처음으로 테스트 시나리오를 작성하는 것이었어요.
## ✏️ 테스트 시나리오
[지동차] - 1순위
- [x] 자동차 이름이 5글자를 초과하면 예외가 발생한다.
- [x] 자동차 이름이 1글자 미만이면 예외가 발생한다.
- [x] 뽑은 숫자가 4일때 1칸 전진해야 한다.
- [x] 뽑은 숫자가 3일때 전진하지 않아야 한다.
- [x] 자동차 생성 시, 이동한 거리는 0이어야 한다.
[자동차들] - 2순위
- [x] 5개의 이름을 받아, 5개의 자동차를 생성해야 한다.
- [x] 중복 이름이 존재하면, 예외가 발생한다.
[등수 계산] - 3순위
- [x] 5대의 자동차 중, 가장 멀리 이동한 자동차의 거리를 반환해야 한다.
- [x] 5대의 자동차 중, 특정 거리만큼 이동한 자동차를 모두 반환해야 한다.
[레이싱 게임] - 4순위
- [x] 시도횟수만큼 모든 자동차가 전진시도를 해야한다.
- [x] 시도횟수가 0이라면, 예외가 발생한다.
- [x] 시도횟수가 -1이라면, 예외가 발생한다.처음이었기 때문에 사소한 것들까지도 많은 고민을 했었는데요
- 정확한 수치까지 명시해야 하나?
- 구현할 클래스 별로 나눠서 작성하는게 맞나?
- 예외 시나리오 말고 기능 시나리오도 작성해야 하나?
- 시나리오를 작성한 뒤 어떤 것부터 테스트를 구현해야 하지?
주로 이런 고민을 했었어요. 이제와서 보니 어느정도 답을 찾은 것 같지만, 그때 당시에는 해당 질문에 대해서 깊게 고민하지 않고 넘어갔었습니다.
이때까지만 해도 테스트 시나리오의 중요성을 깨닫지 못했던 것 같고, 얼른 TDD 사이클을 돌리고 싶어서 일단 무작정 TDD를 적용했었어요.
그 결과가 어땠을까요?
제대로 실패를 해버렸습니다.
"일단 TDD 사이클을 많이 돌리다 보면 언젠간 익숙해지겠지"라는 안일한 생각을 가지고 있었던 것이 이번 실패의 원인이라고 생각해요.
다행히 빠르게 실패를 경험했기 때문에 팀원들과 모여 방향을 수정할 수 있었습니다.
이번 시도를 통해서 저희 모두가 공통적으로 느꼈던 부분이 있었어요.
바로 테스트 시나리오의 중요성이었습니다.
테스트 시나리오 작성에 충분한 시간을 들이게 된다면, TDD 사이클 적용이 쉬월질 것만 같은 느낌을 받았기 때문에 테스트 시나리오 작성에 공을 들여보는 방향으로 나아가기로 했습니다.
🃏 요구사항 분석능력 기르기 (2차 실패)
테스트 시나리오를 작성 능력을 기르려면 어떤 연습을 해야할까요?
저는 이렇게 생각했어요
“테스트 시나리오를 작성한다는 것은 내가 만들고자 하는 서비스의 요구사항을 정확히 이해하고 있다는 가정이 깔려있어야 한다”
그래서 나온 결론이
테스트 시나리오를 잘 작성하기 위해선 요구사항 분석을 매우 잘해야 한다! 이었습니다.
이전까지는 풀어봤던 문제를 다시 한 번 TDD로 해결하는 것이었기 때문에 모든 요구사항을 이해하고 있었다는 특징이 있었어요.
요구사항 분석 능력을 기르기 위해서는 새로운 문제를 해결해 보는 것이 필수적이라고 판단했고, 백엔드 크루들이 하고있던 블랙잭 문제를 받아서 블랙잭 문제의 요구사항을 각자 분석해봤어요.
이건 효과가 있었을까요?
솔직히 말하면 효과가 없었던 것 같습니다.
해당 시도에 대해 회의감이 가장 크게 들었던 부분은 TDD를 학습하고 있다는 느낌이 단 1%도 들지 않았다는 것이었습니다.
요구사항 분석을 잘하는 것이 TDD에 도움이 될 수는 있어도 이 능력만으로는 부족하다고 생각했습니다.
성과 공유회는 점점 다가오고 있었고, 아직도 올바른 방향을 찾지 못한 채로 방황하고 있었습니다.
성과공유회 목적의 주객전도
성과 공유회 이전에 서로 다른 주제의 원정대 팀끼리 리허설을 진행한 뒤 상호 피드백을 하는 시간을 가졌습니다.
최초의 성과 공유회 진행 방식은 TDD를 실천할 때 자주하는 고민 5가지를 선정한 뒤 해당 고민에 대한 저희 팀의 생각을 전달하고, 직접 TDD 사이클을 체험할 수 있도록 했습니다.
처음 원정대 활동에 대해 들었을 때 지식 전수의 느낌이 강했기 때문에 많은 고민을 했었어요.
솔직히 TDD라는 것이 정답이 없기 때문에 일방정인 지식 전수는 저희만의 TDD 기준을 강요하는 것처럼 느낄 수 있었습니다.
하지만 다행히 공유회 며칠 전에 꼭 지식 전수가 아니어도 된다는 피드백을 받게 되었고, 새로운 방향성에 대해서 이야기 해보게 되었습니다.
이 시점에서 또 하나의 의문이 생겼는데요, 지금까지의 방향이 정말 우리가 스스로 학습할 수 있는 방향인가에 대해서 강력한 의심을 품게 되었습니다.
다시 생각해보니 지금하는 활동의 목적이 어떻게 해야 발표를 더 잘할 수 있을까에 더 가까웠어요.
TDD를 나만의 강점으로 만드는 것이 주 목적이었는데, 주객전도가 된 셈이었죠.
그래서 저희가 생각한 새로운 방향은 "토론"이었습니다.
나름 선방한 방향 전환
TDD실천할 때 가장 많이하는 고민 8개를 모아놓고, 저희의 입장을 미리 정해놓는 방식이었어요. 성과 공유회 때는 저희 의견에 동의하지 않는다면 같이 이야기해서 결론을 지어보는 방식으로 하기로 결정했어요.
스스로 학습을 해보자는 관점에서는 이전에 시도했던 방법들보다 효과가 좋았어요.
저희가 정한 입장에 대한 근거도 찾아봐야 했고, 예상 반박을 생각하고 해당 반박에 대해서 어떻게 재반박할지 꼼꼼하게 학습해야 했어요.
가장 효율적인 방식은 GPT와 직접 토론해보는 방식이었어요.
각자 AI와 토론을 열심히 진행한 뒤 모의토론을 진행하는 것으로 공유회 준비를 마쳤습니다.
성과 공유회가 3일 남은 시점에서 방식을 새롭게 변경했기 때문에 최종 결과물의 만족도가 100%는 아니었지만, 꽤 만족할 만한 결과가 나왔다고 생각해요.
결과분석 및 TDD 기준 만들기
저희가 정한 8개의 기준이에요
Q3~Q5까지는 애매한 부분이 있고, 처음 정했던 목표인 나만의 TDD 기준 만들기에 큰 도움은 되지 않는 것 같아서 제외할게요.
Q1, Q2, Q7에 대한 반박은 들어오지 않았기 때문에 입장 그대로 나만의 기준으로 만들어 볼게요.
Q6, Q8에 대한 반박은 들어왔지만.. 기존 입장을 계속 유지할 수 있었던 것 같아요.
어쩌다 보니 기존 입장 그대로 기준을 만들게 되었는데요 ㅋㅋㅋㅋ..
혹시라도 해당 의견에 대해 의구심이 생기신다면 언제든 이야기 해주세요.
토론은 환영입니다
그래서 배운 것은?
크게 2가지 성과가 있던 것 같아요.
첫 번째로 나만의 TDD 기준을 세울 수 있었어요.
나만의 TDD 기준은 앞에서 말한 것을 정리해보자면
1. 설계 단계에서는 각 클래스가 어떤 기능을 가져야 하는지까지 생각
2. getter 테스트는 하지말기
3. 핵심 도메인 로직부터 시작하기
4. mocking 최소화 하기
5. TDD 단계에서 Util 테스트 하지 말기이정도로 요약해볼게요.
두 번째, TDD의 목적을 남에게 설명할 수 있게 되었어요.
제가 생각한 TDD의 목적을 한 줄로 요약해본다면
"도메인 중심으로 튼튼한 설계를 확장해 나가기 위함"이에요.
이렇게 말하니까 어디까지가 TDD단계인지도 생각해볼 수 있게 되었어요
뭉뚱그려 이야기 해보면 "도메인 설계가 끝날 때까지" TDD를 실천하면 되고,
조금 더 구체적으로 이야기 해본다면 단순 Input, Output과 관련된 작업은 제외하고 도메인 관련 객체들의 상호 협력 전까지라고 볼 수 있을 것 같아요.
마무리
팀별로 작성한 회고 공유와 함께 마무리 해볼게요.
잘한 점
- 효과가 미비하다고 생각된 활동 내용을 회의를 통해 과감히 바꾼 것이 좋았던 것 같다.
- 서로 생각하는 방향이 달랐을 때, 같이 의논하며 맞춰가는 시간을 가졌다.
- 토론 형식으로 진행하여 TDD의 방향성을 잡을 수 있게 되었다. (찬-반 의견 모두 학습함으로써 각각의 장단점을 알 수 있었음)
- TDD를 실천할 때 자신만의 기준을 어떻게 잡으면 좋을지 알게 되었다.
아쉬운 점
- 정답이 없는 분야여서 방향성을 정하는데 시간이 오래 걸렸다.
- 주제 공부 - 전달 방향 및 내용 사이의 적당한 위치를 찾지 못했다.
- 100% 이론보다는 실습도 섞어서 학습했으면 효과적으로 할 수 있었을 것 같다.
- 참고서를 하나 정해서 갔으면 더 좋았을 것 같다 (너무 본인 생각만 이야기 했다)
액션 플랜
다같이 참고할 자료를 1개 정해보자.
다음에 비슷한 활동을 한다면 꼭 공통적으로 참고할 자료를 1개 이용할 생각이에요.
처음부터 각자의 생각만으로 이야기를 하다보니 쉽게 결론이 나지 않았던 부분이 많았던 것 같네요.
