도전 TDD! - 화폐 예제
테스트 주도 개발 1부 화폐 예제
6/23/2024, 11:07:00 PM
앞서 테스트 주도 개발의 패턴 파트를 먼저 읽고, 1부 화폐 예제로 돌아와 수련을 시작했다. 먼저 한번 글로 쭉 읽은 뒤에 직접 구현하면서 다시 한번 예제를 따라해보았는데 확실히 눈으로 코드를 쫓을때 보다 직접 코드를 치면서 느껴지는 부분이 많았다.
책에서는 Java로 진행했지만 나는 Kotlin 으로 진행했으며 그 결과는 깃헙 에 공유해두었다. TDD의 규칙은 너무 단순해서 오히려 그래서 어떻게 실천하라는 건데? 라는 생각이 들었었는데, 이 예제를 진행하면서 TDD에서 추구하는 방향성에 대해 조금은 명확하게 이해하게 되었다. 이 단순한 규칙 속에 함축된 많은 의미와 의도를 파악할 수 있었다.
규칙1. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
규칙2. 중복을 제거한다.
소감
천천히 진행하기
TDD의 큰 효능 중 하나는 ‘천천히 진행하는 방법’ 을 알려준다는 점인 것 같다. 예제 진행의 초반부는 심하다 싶을 정도로 뻔히 어떻게 구현해야 하는지 예상되는 코드도 매우 작은 보폭으로 진행된다. 그러면서 자주 강조하는 것이 “항상 반드시 이런 보폭으로 나아가야 하는 건 아니지만 중요한 것은 이렇게 할 수 있어야 한다” 라는 것이다. 실제로 나는 다소 복잡한 스팩을 구현해야 할때 막막함에 사로잡히기도 하고, 종이에 이리저리 설계를 그려보느라 많은 시간을 보내기도 한다. 그렇게 아주 많은 생각을 가지고 조심스럽게 코딩을 진행하다가도 마음에 들지 않거나 제대로 동작하지 않아 다 지워버리는 경우도 있다. TDD를 통해 진행한다면 아주 자신감이 있는 경우에는 큰 보폭으로 진짜 구현을 하며 나아갈 수도 있고, 그러다 막히면 안전한 곳(테스트가 모두 통과했던 시점)으로 돌아와 작은 보폭으로 천천히 진행할 수도 있다. 이번 진전의 범위를 조절하여 침착하고 자신감있게 계속 나아갈 수 있다.
TDD is NOT Magic
TDD는 마법이 아니다. TDD만으로 훌륭한 설계나 아이디어가 저절로 생겨나지는 않는다. 특히 책에서는 메타포라는 말을 사용하는데, 어떤 방식으로 이 문제를 바라보고 무엇이 비유하여 구현할 것인가 하는 부분은 순전히 저자의 아이디어에서 출발한다. 예를 들어 여러 통화 화폐들의 합이나 곱은 지갑 같은 것에 비유하여 Wallet 이라는 클래스를 정의하거나 할 수 있지만 저자는 각각을 단위(화폐) 간의 연산(Expression)으로 표현한다. 또 환율 처리를 담당하는 Bank 라는 개념을 도입하는데 결과적으로 객체의 역할과 책임을 적절하게 나누기는 했지만 이 역시 작가의 직감에 의존한 설계였다(직접 그렇게 언급함). 다만 TDD는 이러한 아이디어와 다양한 설계를 자신감있고 변화무쌍하게 시도해볼 수 있는 가장 좋은 방법이다.
Top-Down 설계
테스트를 먼저 작성한다는 것은 객체 간의 역할과 책임을 가장 먼저 생각한다는 것과 같은 말이다. 테스트를 먼저 작성하기 위해서는 아직 존재하지도 않는 객체와 메서드를 테스트 코드에 사용해야 한다. 그 과정에서 이 객체가 어떤 역할을 가지면 좋을지, 어떻게 외부에 노출되면 좋을지, 어떤 식으로 다른 객체와 협력하면 좋을지 먼저 생각하게 된다. 특히 메서드 수준에서 이러한 모습이 가장 도드라진다. 기존에는 메서드를 구현하면서 어라? 이 함수를 호출하려면 이것도 넘겨 받아야하네? 하는 식으로 구현하는 와중에 메서드의 모습이 변화하는 경우가 많았다. TDD에서는 이미 테스트 코드에서 wannabe 모습을 적어두었기 때문에 뭔가 추가로 필요하다거나 하면 객체의 역할이나 메서드의 범위에 대해 다시 생각해보게 된다.
Inner Peace
빨간불을 보는 개발자들의 불안한 심리를 굉장히 잘 활용했다고 생각한다. 예제를 따라가는 것일 뿐인데도, 테스트가 딱 깨지면 상당히 초조해졌다. 왜 책에서 자꾸 빨강-초록 리듬이 중요하다고 하는지 알 수 있었다. 그 반대로 초록불 상태가 되면 내적 평화가 찾아온다. 무한히, 조심스럽게, 확실하게 나아가는 좋은 수단임은 확실하다.
댓글
* 작성 이후에 수정/삭제 할 수 없어요!
아직 작성된 댓글이 없습니다.