Vue TDD - 회고편

📌 목차

• 서론
• TDD를 하면서 겪었던 어려움들
• TDD를 하면서 좋았던 점들
• 결론

📌 서론

이번 포스팅에서는 그동안 다뤘던 tdd에 관해 회고 해보는 포스팅 입니다. 개인적으로 tdd를 하면서 겪었던 어려움들 그리고 느꼈던 생각들을 정리해 보는 포스팅입니다.

📌 TDD를 하면서 겪었던 어려움들

TDD를 하면서 겪었던 어려움들은 다음 세가지가 있습니다.

1. 어디까지 test를 해야할까?
2. 어떻게 하면 의존성을 줄일 수 있을까?
3. testcase가 잘못 되면 어쩌지?

1. 어디까지 test를 해야할까?

모든 코드를 test code로 커버한다는 것은 매우 어렵고 비생산적인 일입니다. 그렇다면 어디까지 testcode를 작성을 해야할까요? 어느 부분에서 실수가 가장 많이 날까요? 이런것들은 어쩔수 없는 경험이라고 생각합니다. 그래서 testcode를 처음에는 공부하듯이 모든 것을 테스팅해보는 방법으로 가고 점차 이런 부분은 굳이 해야할까? 이런 부분에서는 test가 필요없을거 같아. 라고 하는 부분이 생기게 됩니다. 그럼 그때 차근히 줄여나가고 정말 필요한 부분들을 test를 하는 경험이 필요합니다.

2. 어떻게 하면 의존성을 줄일 수 있을까?

테스트를 하면서 가장 크게 고민을 했던 부분들은 최대한 경량화 하여 기능이 추가되어도 기존의 test가 깨지지 않게 하는 것입니다. 너무 작은 단위로 쪼개지면 testcode만 많아질 뿐 아니라 가독성이 너무 떨어지는 문제가 발생하게 됩니다. 그래서 이부분 또한 경험에 의한... 이라고 말을 할 수 없을 것 같습니다...😭

3. testcase가 잘못 되면 어쩌지?

잘못된 혹은 커버하지 못하는 testcase가 있을 수 있습니다. 이때 내가 짠 test code는 얼마나 신뢰할 수 있느냐 라는 문제에 직면 하게 됩니다. 이부분도 경험에 의해 쌓여가야 하는 부분인 것 같습니다. 저 같은 경우 오픈소스에 다른 사람들이 짜논 test code를 한번씩 보는 것 어떤 식으로 테스트를 하나를 경험해보면서 자기 것에 하나하나 적용해가 보는것 입니다.

📌 TDD를 하면서 좋았던 점들

TDD를 하면서 가장 좋았던 점은 코드가 정돈이 되는 것 그리고 debug하는 시간이 기하급수적으로 줄었다는 것 입니다. 초반에는 test case를 짜보느라 개발 시간이 늘어났지만 전체적으로는 debug하는 시간이 줄었기에 개발 시간이 줄었습니다. 이부분은 굉장히 좋았습니다.

또한 자기자신에 대한 끊음 없는 도전입니다. 테스트 코드를 짜면서 하다보니 자연스래 자기 자신에게 부족한 부분들이 보였습니다. 코드의 간결성, 논리의 흐름, 디자인 패턴 등 끊임없이 부족한 부분들이 보이고, 이부분은 이렇게 더 간소화할 수 있진 않을까? 하면서 자극이 많이 되었던거 같습니다.

📌 결론

TDD가 만능이라고 생각하지는 않습니다. 더 좋은 개발 방법론이 있을수도 있고 상황에 따라 TDD를 하는 것보다 다른 방법론을 하는 것이 더 좋을 수도 있습니다. 특히 view에 관한 부분은 testing을 하는 것이 과연 옳은 일일까? 사람의 눈이 더 좋은거 같은데... 라고 생각을 했던 적이 있습니다. 그리고 view를 테스팅 하는 부분에 대해서는 아직까지도 testing을 하기 보다 직접 한번 더 보는 것이 맞다고 판단이 되어지기도 합니다. 하지만 많은 부분 TDD는 정말 좋은 방법론 이었고 이 방법론을 사용하여 많은 영감을 받았었습니다. 그래서 이글을 통해 다른 개발자들이 제가 느겼던 경험들과 영감을 얻어 더많은 좋은 TDD에 관해 토론하는 장이 있었으면 좋겠습니다. 그동안 Vue - TDD편을 읽어주셔서 감사합니다.