TDD 💎

 

 

🌸 TIL

 

 

TDD

 

 

회사에서 React Native + TypeScript 를 사용하여 프로젝트를 진행하면서 뒤늦게 TDD를 도입하게 되었다.

TDD의 필요성을 느끼지 못했고, 그저 요구사항을 구현하기 급급하다는 핑계로 TDD 도입을 뒷전으로 미루었는데 프로젝트 기능을 하나하나 추가해 나가면서 복잡한 로직들이 늘어나게 되었고 기능이 제대로 작동하고 있는지 일일이 테스트하는 것도 번거로워졌다.

 

 

 

 

 

🔎  선 기능구현, 후 TDD 

 

 

처음에는 기능을 먼저 구현하고 나중에 TDD를 작성하여 테스트하는 방식을 적용했었다.

TDD의 의미는 "테스트 주도 개발" 인데 선 기능구현 후 TDD를 한다는 것은 TDD의 존재의미를 잃게 되는 것이고 테스트 주도 개발이라고 볼 수 없다. 

 

기능을 다 구현한 후 몰아서 작성한 테스트 케이스는 당연히 100% 성공하는 케이스로 작성할 수 밖에 없을 뿐더러 이 코드를 왜 작성했는지 의미조차 명확해질 수 없다.

 

테스트케이스에 통과되지 못하는 코드를 작성하여 실패를 마주하기 싫었던 것이고 그저 " TDD가 좋다고 하니까 보여주기 식으로 내 코드에도  대충 욱여넣어볼까? " 라는 생각을 했던 것이었다.

 

 

 

 

🔎  선 TDD, 후 기능구현

 

 

TDD를 도입함으로써 설계 관점에서 여러 상황들을 열어두고 보게되는데 이러한 열린 설계 방식이 안정성 높고 확장성 높은 코드를 작성하는데 도움을 주었고 실제 코드에 대한 명확한 처리를 설계함으로써 과도한 설계를 피할 수 있었다.

 

내가 작성한 코드에 대해서 생각하게 되고 이 코드를 왜 작성할 것인지에 대해 의도가 좀 더 명확해지는 장점과 테스트케이스를 미리 설계함으로써 아웃라인이 그려진다는 장점을 느낄 수 있었다.

 

물론 테스트케이스를 작성함으로써 초반에 시간을 할애하게 되긴 하지만 TDD를 작성한다면 설계측면에서도 좋은 설계를 할 수 있을 것이고 개발 생산성 또한 향상시켜줄 것이다.

 

테스트 케이스를 작성할 때에는 대부분 작은 단위로 만들기 때문에 코드를 명확하게 분리할 수 있고 분리된 코드는 자연스럽게 모듈화가 되어 개발을 진행하게 된다. 또한 의도하지 않은 값을 전달하였을 때, 타입스크립트가 충분히 친절한 에러를 보여주겠지만 덜 안전한 코드보다 더 안전한 코드를 싫어하는 개발자는 없을테니 이 것도 큰 장점이 될 수 있겠다.

 

아직까지는 선 TDD작성 후 기능구현이 익숙하지 않아서 코드를 작성하다보면 내가 TDD를 작성하고 있다는 사실을 잊어버리게 되지만 꾸준히 습관화 한다면 주니어 개발자인 지금이 TDD를 습관화 하기에 딱 좋은 시기일 것이라고 믿는다.

 

 

 

 

---

 

마치며 🌸

 

TDD의 의미는 "테스트 주도 개발" 이라는 것을 잊지 말고 기능구현하기 급급하여 무작정 코드작성으로 달려들지 말고 차근차근 TDD를 작성하여 테스트가 개발을 이끌어 나갈 수 있도록 해야겠다.

 

테스트 케이스가 잘못 짜여지면 존재의 의미를 잃게 되어서 생각이 많이 필요하다.

하지만 " 잘 짜여진 테스트 케이스를 통과하는 좋은 설계 " 로 부터 오는 기쁨을 느껴본다면 TDD를 도입하지 않을 이유가 없다고 생각한다.

 

 

 

 

 

( 이렇게 TDD가 좋다좋다 해놓고 내일 출근해서 코드를 작성하면 난 또 TDD 작성을 깜빡하겠지.............?....... 얼른 습관화해야겠다..........^^................😂 )