[ je 개발 공유 ] TDD

 

 

  예전에 TDD, Jest 로 테스트 하는 방법과 관련해서 발표를 했을 때의 자료다. 발표 당시의 나는 입사한지 1달 밖에 되지 않았기에 경험에서 우러나오는 테스트의 필요성이 아닌 이론적으로 테스트가 왜 필요한지에 대해서 자료를 조사하고 발표했던 것 같다. 

 

  슬프게도, 나는 이 발표 이후에 만든 도메인 하나에만 작게 Test 코드를 만들어 놓았고, 이번에 한 L 프로젝트에서는 테스트 코드를 따로 작성하지 않았다. 그러면서 경험적으로 이제 테스트 코드가 필요하다고 깨닫게 됐는데, 한 번 이 시점에서 옛날에 했던 발표는 어땠는지 돌아보는 것도 재밌을 것 같다.

 

  참고로, 당시에 발표 재밌게 해달라는 그룹장님의 요청이 있어서... 여러 밈들을 섞어가며 재밌게 만들어보고자 노력했다. 

 

Jest 테스트.pdf

1.98MB

  (Tistory 은 기본적으로 PDF 미리보기 기능이 없구나..)

 

 몇 가지 하이라이트 슬라이드만 가져와서 글을 적도록 하자.

 

1. 테스트의 필요성

 

 

 

  나는 저 테스트의 필요성 모두 공감하는데 특히 2번이 진짜 찐 이유다. 위에 링크를 달았지만... 나는 이번 L 프로젝트에서 정말 호되게 요구 사항에 치였다. 테스트 코드는 진짜 그런 면에서 굉장히 유용한 것 같다. 일단, 테스트 코드를 한다는 것 자체에서 함수에 많은 일과 역할이 부여되지 않게 만들 수 있다. 명령형으로 쭉 나열하는 코드가 아닌, 자기 역할이 명확한 함수들로 쪼개서 코드를 작성할 수 있었을 것이다. 또, 테스트 코드를 작성하면 문제가 발생했을 때 어디에서 문제가 발생했는지 빨리 찾을 수 있고, 문제가 없다면 기존의 동작은 모두 잘 될 것이라는 안정감이 있기에 "아 또 망가지면 어떡하지?" 라는 불안감에서 해방될 수 있을 것 같다.

 

 

 

2. FIRST

 

 

  TDD 를 하는데, FIRST 규칙을 지켜야 한다. 일단, 테스트는 빠르게 돌아가야 한다. 이거 정말 맞다. 내가 개발하다가 빌드하는데 오래 걸리면 빌드하기 너무 싫다.(그래도 해야겠지만..) 마찬가지로 만약 테스트가 빠르게 돌아가지 않는다면 답답해서 테스트 꺼놓고 나중에 배포할 때쯤에나 한 번 할 거 같다. 그러면 그 좋은 Watch 기능을 사용할 수 없는 것이기에 개인적으로는 테스트 빨리 돌아가야 한다는 것에 동의하고 라이브러리 선정에 있어서 이게 중요한 포인트가 될 것 같다.

 

  각 테스트는 서로 의존해서는 안 된다는 것도, 이게 만약 테스트끼리 의존해버린다면, 이는 곧 테스트 자체가 순수하지 않다는 것을 의미하기도 한다.

 

  개인적으로 Repeatable 규칙을 굉장히 중요하게 생각하는 편이다. 네트워크가 연결되지 않은 상황에서도 테스트는 돌아가야 한다. E2E 테스트라면 얘기는 달라지겠지만, 함수의 기능을 테스트하는데 네트워크 연결이 끊겼다고 해서 테스트를 할 수 없는 상황이 온다는 것은, 잘못된 테스트라 생각한다. 만약 네트워크 요청과 관련된 테스트를 만든다고 한다면 Mock API, Response Data 를 만들고, 각각 다른 Status 코드 (200번대, 400번대, 500번대 등) 를 보내면서 테스트 케이스를 더 만드는 것이 좋다고 생각한다.

 

  Timely 가 TDD 에서 정말 중요한 내용이지 않나 싶다. 테스트 하려는 코드 구현 전에 먼저 작성하는 것이, 내가 지금 어떤 함수를 만들려고 하는지 확실하게 알고 가는 것이고, 또 실제 비즈니스 코드를 작성하기 전에 테스트 코드를 위해 한 번 더 생각하므로 코드의 질이 높아질 수 있다. 

 

 

3. 현실은 시궁창?

  내가 이 발표를 했을 때, 지금의 부문장님이 "현실은 시궁창이다. 저렇게 하고 싶다고 하지만, 결국 코드를 구현하다 보면 TDD 할 수 없다." 라고 말씀하셨다. 

 

  ...나는 유구무언이다.

 

  진짜 이번에 L 프로젝트를 만들면서.. 정말 시궁창을 경험한 것 같다. 그래도 TDD 해보겠다고 vitest 도 깔고 해봤는데, 막상 내가 다 기획도 하고 개발도 하고, 요구사항을 너무 많이 받다 보니, 변명 아닌 변명으로 테스트 코드를 작성할 시간이 없었다. ...반성해야 한다.

 

반성하자

 

  

  나도 조금은 테스트 코드를 작성하지 않은 것에 대해서 진짜 어쩔 수 없었다고 말하고는 싶다. 그렇다면 중요한 것은 앞으로다. 앞으로도 테스트 코드를 작성하지 않을 것인가? 그렇지 않다.

 

  부문장님이 저렇게 말씀하셨을 때 내가 한 대답은, 현실은 시궁창이지만 이상을 포기할 수 없다. 라고 말했었다. 비록, 지금은 테스트 코드 하나 없이 기술 부채가 많이 쌓여 있는 상황이지만 지금이라도 리팩터링으로 하나씩 테스트 코드를 작성해 나가면서 기술 부채를 줄여 나가야 하고, 또 그렇게 해야 한다. 요즘 테스트 코드의 중요성을 너무 뼈저리게 느껴서 KPI 에 테스트 코드 작성이라고 까지 쓰여 있다. 앞으로는 테스트 코드를 잘 작성해서 아래와 같은 서비스를 만들어야 겠다.