TDD란?) 클린 코드(로버트 C. 마틴) 9장 단위테스트

개발을 하다보면 구렁텅이에 빠지는 기분이 들때가 있다..

나는 요즘 회사 내에서 사용할 알림 기능을 개발중이였다.. 설계는 내가한 것이 아니고 받았다. DFD를 받았고 충분히 설명을 들었다. 근데 이제 개발을 들어갔는데 그런 기분이 든다.

시간은 시간대로 쓰는데 목표는 없는 기분이고 생각은 멈춰있다.. 집중력 부족인것 같고 해낼 수 없을 것 같은 기분이 든다.. 이 모든게 내가 마음속에 TDD를 새기면 해결이 될까..? 일단 공부해본다.. 왠지 TDD가 해결해 줄 것 같기도 하고...

 

일단 어쩔 줄 모르겠는 마음으로 산 클린 코드(로버트 C. 마틴, 인사이트)의 9장: 단위테스트를 읽어본다.

9. 단위 테스트

TDD 법칙 세가지

"지금 즈음이면 TDD가 실제 코드를 짜기전에 단위 테스트부터 짜라고 요구한다는 사실을 모르는 사람은 없으리라"

* 출처 : 로버트 C. 마틴, 클린코드((주)도서출판인사이트, 2021) 

난 몰랐다.. 일단 나는 단위테스트를 어떻게 짤지 생각을 하면서 실제 코드부터 막 적었던것 같다.. 일단 마음에 새겨야 할 말중 하나인 것 같다

 

• 첫째 법칙 : 실패하는 단위테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  • 내가 단위테스트를 할 단위에 대해서 실패를 시킬 테스트 코드를 적어놓고 시작을 하라는건가..?
• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.
  • 음 이해가 잘 가지 않는다.. 첫번째 법칙에 대한 부가적인 얘기인것 같은데 컴파일은 실패하지 않으면서가 갖는 의미가 뭐지 당연히 컴파일은 실패하지 않아야하는거 아닌가
• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
  • 실제코드를 잘 작성을 하면 테스트를 통과할테니 만들어놓은 테스트케이스를 통과할 정도까지만 실제 코드를 작성하고 다음 테스트코드를 또 만들라는 이야기 같다.

이렇게 되면 굉장히 많은 테스트 코드가 나오는데 이거를 잘 관리하는 것도 실제 코드를 작성하는 것 못지 않게 중요하다는 얘기도 다음 장에 나온다. 마음에 새길 두번 째 문장인것 같다. 테스트 코드를 적고 개발이 진행되면서 버리게 되는 경우가 많았던것 같다. 컴파일 오류가 발생하게 되니까(아 이게 위의 두번째 법칙이랑 관련이 있는 건가) 그냥 주석처리해버리는 경우나 아예 테스트 코드를 삭제해버리는 경우도 있었다. 앞으로는 절대 그러지 말아야겠다.

 

깨끗한 테스트 코드

"깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성.

* 출처 : 로버트 C. 마틴, 클린코드((주)도서출판인사이트, 2021) 

피식했다ㅋㅋ. 마음에 새길 세번째 문장.

 

테스트 당 assert 하나

"그러므로 가장 좋은 규칙은 "개념 당 assert문 수를 최소로 줄여라"와 "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.

* 출처 : 로버트 C. 마틴, 클린코드((주)도서출판인사이트, 2021) 

F.I.R.S.T

• Fast : 테스트는 빨라야 한다.
• Independent : 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다.
  • 나는 이랬던 경험이 있던 것 같다. 이제와 생각해보니 이런 것들은 테스트가 깨끗하게 유지되는데 방해가 되기 쉬운것같다.
• Repeatable : 테스트는 어떤 환경에서도 반복 가능해하 한다. 실제 환경, QA환경 버스를 타고 집으로 가는 길에 사용하는(네트워크에 연결 되지 않은) 노트북 환경에서도 실행할 수 있어야 한다.
  • 이게 단위테스트에서 진짜 중요한 내용 같다. 단위테스트를 작성을 하는것은 같이 협업할 다른 개발자를 위해서라도 필요한 것이기 때문에 그냥 run을 했을 때에 돌아가게끔 테스트를 작성을 해야한다.
• Self-Validating : 테스트는 부울 값으로 결과를 내야한다.
  • 나는 여태까지 단위테스트라고 해봤자 해당 코드를 테스트하고 받은 무언가를 출력하는 게 끝이였는데 이렇게 되면 다른 사람이 내가 작성한 단위테스트 함수를 실행했을때 성공인지 실패인지 바로 직관적으로 알 수 없는게 문제가 되는것 같다. 앞으로는 assert를 작성해서 직관적으로 알 수 있게끔 조금 더 신경을 써서 작성해야겠다.
• Timely : 테스트는 적시에 작성해야한다.
  • 앞서 나왔던 내용과 같은 내용이다. 단위테스트는 실제 코드를 구현하기 전에 구현한다. 이렇게 되면 단위테스트를 위해 나눈게 모듈화의 기준이 될수도 있다.

 

일단 내가 앞으로 나가지못하고 목표가 상실된 것 같은 기분은 TDD를 마음에 새기지 않아서라고 혼자서 추측하고 책을 읽어봤다. 물론 요만큼 읽었다고 TDD를 알게 된건 아니지만 알림 기능이라는 것에 대해서 작게 작게 단위테스트를 전부 작성하고 그것들을 모은다는 식으로 진행을 하면 목표 없이 흐리멍텅하게 개발하는 건 아니게 되지 않을까.. 일단 지금까지 개발한 모든걸 버려버리고 다시 개발을 해야겠다. 위에서 읽은 것을 토대로.. 한번 그 과정도 내가 글을 쓸수 있다면 써봐야겠다.

 

* 모든 내용의 출처는 클린코드(로버트 C.마틴, (주)도서출판인사이트, 2021) 입니다.