서론

항해플러스라는 교육과정에서 3주에 걸쳐 TDD에 대한 경험 및 코칭을 받게 되었다.
3주간의 시간을 회고해보는 의미로 본 글을 작성하게 되었다.

본론

TDD 무조건 좋을까?

번거로움

몇몇 코치님들은 TDD에 대한 개념을 설명해주시기 전에 본인은 TDD를 별로 안좋아 한다고 말씀하시기도 했다.
그 이유는 테스트 코드 및 기능개발이 완료된 상태로 통합 테스트시 의존성이 있는 테스트 코드를 수정해야하면 다른 테스트코드들을 전부 수정했던 번거로운 경험이 있으셨다고 하셨다.

느린 개발속도

또 하나의 이유는 개발속도가 느려지는 단점이 있다고 하셨다.
물론 TDD를 도입함으로써 설계를 좀더 탄탄히 가져나가서 추후 유지보수성을 높이는 효과를 줄 수 있지만, 설계에 이미 시간을 많이 투자했기에 실제 서비스를 만들때 까지 생각보다 많은 시간이 소요될 수 있다는 것이다.

TDD의 효과

유지보수성 증가

TDD를 진행해보면 느끼는게 설계단계에서 유스케이스부터 시작해서 파생 될 여러 성공시나리오, 실패시나리오 등을 미리 사전에 생각해두고 사고를 방지할 수 있는 개발방식이라고 느껴졌다.
이 과정이 사실 좀 지루하게 느껴지고 제대로 하고있는건지 모르겠다는 생각은 필자가 TDD를 처음해보는 것과 더불어 잘 모르는 도메인에 대한 유스케이스를 생각하려다 보니 그랬던거 같다.
따라서 도메인에 대한 이해가 있다는 가정하에 좀더 좋은 유스케이스를 써내려갈 수 있을거 같았고 보다 안정적이고 유지보수성이 높은 코드를 작성 할 수 있을것으로 기대된다.

테스트가 끝났을때 퇴근이 가능함

기본적으로 TDD의 싸이클은 작성된 유스케이스를 기반으로 테스트코드를 작성하고, 테스트를 진행해보면 실패를 하게된다.(아무것도 구현된게 없기 때문이다.) 이어서 테스트를 통과 할 수 있도록 기능구현을 진행하고 테스트를 진행해보면 테스트를 통과하게 된다. 이어서 테스트를 통과는 하지만 좀더 리팩토링이 필요한 부분이 있을텐데, 리팩토링을 짧은 호흡으로 진행하게 된다. 그러고 다시 테스트를 진행하고 모든 테스트가 통과한다면 예정된 유스케이스에 대한 기능구현이 끝난 것으로 퇴근이 가능하다!

결론

TDD는 직접 경험을 해보니 도메인에 대한 이해가 필요하다는 것과 먼저 경험을 해본사람이 코칭이나 리딩을 해주어야 처음해보는 입장에서는 따라가기가 수월했던 과정이였다.
개발 전체 단계중 초반의 설계단계를 많이 잡아먹은 만큼 기능 구현단계에서는 빠르게 구현이 가능했다. 테스트 코드를 믿고 편하게 진행을 하면 된다는 것이 안정감을 주는 개발방식인 거 같았다.
하지만 역시 도메인에 대한 지식이 부족하다보니 생각 보다 설계단계가 쉽지 않고, 빠트린 부분도 있을 것이며 시간도 오래 걸린거 같다.