개발자로 일하며 TDD 환경에서 많은 프로젝트를 진행해왔고, 그러다보니 "아 이게 TDD란 것이구나!"라는 것을 깨닫게 되었다
하지만 지금에와서 다시 한번 곰곰히 뜯어보며 코드를 작성하니, 그 조차도 틀렸고 한번 더 깨닫게 된 부분이 있었다
그 과정을 지금 공유해보려고 한다
앞으로의 글은 TDD와 DDD에 대해 설명한 후에, 간단히 인증 관련한 기능을 두 방법론을 가지고 구현해보려고 한다
단순히 인증만? 도메인이 하나인데 무슨 DDD야, 적어도 프로젝트 하나라도 해봐야지!
라고 생각할 수 있지만, 실무와 공부는 다르다고 생각한다
무릇 개발 공부란 실제 개발에 적용하기 위해서 간단한 것부터 찬찬히 뜯어보며, 코드 한줄 한줄을 왜 그렇게 작성한 것인지 스스로 기준을 정립해가는 것이라고 생각한다
프로젝트에 직접 적용해보는 것은 그런 기준이 생긴 이후의 일이다
1. 올바른 개발 습관을 들이자!
TDD 란 모두들 알다시피 Test Driven Development의 약자로, 테스트를 주도로 하는 개발이다
이름이 개발방법론이다 보니 마치 엄청난 무슨 기술처럼 느껴지기도 한다
실제로 필자는 취준생 때, 개발방법론과 디자인 패턴을 엄청난 기술로 여기고 "연구"했을 때가 있었다
그리고 내가 본 개발자들 중에서도, 간혹 TDD를 엄청 심오하고 온 신경을 써야하는 것으로 이야기 하는 사람들이 종종 있다
하지만 그렇지 않다. TDD는 단순히 좋은 개발 습관을 들이는 방법이라고 생각한다
이게 무슨 소린가하면, 다음을 살펴보자
2. 잘못된 개발 습관
일반적으로 개발을 진행하는 순서를 나타내보았다
- 일단 코드를 작성하거나 수정한다
- 잘 동작하는지 돌려본다(실행)
- 컴파일 에러가 난다? -> 아 여기 코드 작성이 잘못됬네...(1번으로)
- 실행은 잘 되네. API로 요청을 날려보자
- 다른 Exception이 발생한다 -> 왜 그러지..여긴가?(1번으로)
뜨금 하는 사람들이 있을 것이다. 저것이 왜 잘못된 것일까?
크게 3가지를 꼽을 수 있다
로컬이지만 사실은 운영 코드!
아무리 로컬이라지만 소소한 환경만 다를 뿐, 운영처럼 모든 의존성들이 주입되어 실행이 된다
즉, 우리가 코드를 작성하는 순간 그것은 Production Code이다
이를 마음대로 수정하고 실행하고 하는 것은, 과장하면 운영서버를 대상으로 테스트하며 수정하는 것과 같다
효율이 좋지 않다
웬만한 프로젝트는 실행하는데에 시간이 꽤 걸린다. 앞서 말했듯 모든 의존성이 같이 올라가기 때문이다
이를 계속 반복하는 것은 시간적으로나 성능적으로 매우 낭비되는 행동이다
또한 이것저것 수정하다보면 결국 방금 어떤 걸 바꿨는지, 뭘 위해 수정하는지 대부분 잊어버린다
이는 코드의 안정성을 저해하는 일을 발생시킨다
생각하지 않는 버릇
코드를 작성하기 전에는 내가 뭘 위해 개발을 하는 것인지 충분히 정리하고 숙지한 후에 진행해야 한다
그런데 일단 손 가는대로 작성을 하다보면 생각하지 않고 작성을 하게되고,
이는 결국 나중에 오류가 발생했는데 어디서부터 손대야할지 모르는 상황이 벌어진다
3. 올바른 습관이란!
그럼 올바른 습관이란 뭘까? 복잡하게 생각할 것 없다. 아래 3원칙만 지키며 작성하면 된다
3 원칙
1. 반드시 테스트를 먼저 작성해야 한다
2. 오로지 테스트가 성공하기 위한 코드를 작성해야 한다
3. 테스트 성공 후에는 반드시 코드 정리만 수행해야 한다
이를 도식화하면 유명한 다음의 그림이 나온다
출처: https://velog.io/@hwsa1004/STUDY-TDD%EA%B0%80-%EB%AD%94%EB%8D%B0
그럼 원칙에 따라 올바른 습관이 무엇인지 알아보도록 하자
0. 뭘 작성할지 생각하기
가장 지루하지만 꼭 필요한 과정이다. 지금 내가 뭘 구현할지를 알아야 한다
이게 완료되야 다음 단계가 진행이 된다
생각하는게 막막하다면 차근차근히 프로세스를 시각화해보거나 정리해봐도 좋다
UML을 그리든, 다이어그램을 그리든 본인만의 방법으로 정리하면, 당장 뭘 해야하는지가 나온다
보통 간단한 기능 하나부터 구현해야 할 경우가 많을텐데, 이렇게 진행되는 것이 바로 "단위 테스트"이다
1. 테스트 먼저 작성
이 단계의 테스트는 구현할 기능을 완전히 대변할 수 있어야 한다
즉, 이걸 모두 성공한다면 최소한 그 기능은 문제 없어!가 되어야 한다
한번에 다 적으려고 하거나, 뭔가 대단한 것을 적으려고 할 필요는 없다
하나의 기능을 위해 테스트는 추후 얼마든지 추가될 수 있기 때문이다
어떻게(How) 작성해야 할지 모르겠다면 간단히 성공/실패 케이스로 나눠서 작성해보면 된다
2. 테스트만 성공하기 위한 코드를 작성
오로지 테스트를 통과하기 위한 코드를 작성해야 한다
이 단계에서 아예 모든 코드를 다 작성해버리는 경우가 있는데, 그러면 의미가 없다
조금 이상하더라도 오로지 통과를 위한 코드를 작성하자
3. 코드 정리 수행
앞선 테스트의 성공을 보장하기 위해, 코드만 정리하도록 한다
절대 프로세스에 수정이 있어서는 안된다
그렇게 되면 테스트의 완정성이 깨지게 된다
따라서 변수를 다듬는다거나 하는 등의 간단한 정리를 진행한다
4. 다시 1단계로!
작성한 Production Code를 보면 원하지 않는 코드가 작성되었거나, 완벽하다고 생각했는데 버그가 나는 경우가 있다
이 경우는 테스트가 부실한 경우이다
따라서 어떤 부분이 부족한지, 버그는 그에 대한 구체적인 원인을 파악하는 1단계로 넘어가도록 한다
4. 문제점?
하지만 TDD의 테스트에만 너무 열중하다보면 한가지 문제점이 발생하게 된다
이때 생각해 볼 수 있는 것이 바로 BDD 인데, 이 부분이 바로 필자가 잘못 알고있던 부분이다
이는 다음에 알아보도록 하자
