서론

• 초보 개발자의 이야기 이다보니 틀린 내용이 다소 있을 수 있습니다. 주관적인 느낌이라고 생각하고 읽어주시면 감사하겠습니다. 틀린 부분이 있다면 댓글로 피드백 부탁드립니다.☺️☺️👏

• 글을 쓰게 된 이유는 side-test 의 unit-test 의 code coverage 를 100% 로 한번 완성해 보았습니다. 전체적인 부분은 아니고, 특정 비즈니스 로직에 대한 test-code-coverage 를 100%로 작성해보았습니다. 이러한 과정을 거치며 느낀점을 서술해보려고 합니다.

본론

테스트 코드란?

• 말 그대로 코드를 테스팅 할 수 있는 코드를 작성하는 것! 그렇다면 왜 코드를 테스트 하는 코드가 필요할까?🧐 코드의 버그를 줄이기 위해서? 우리의 Product 가 이정도의 신뢰성을 보여준다는 것을 보여주기 위해서? 이유는 많을 수 있고, 각 개인의 회사 혹은 프로젝트의 방향성에 따라 달라질 수 있다고 생각한다. 이 부분에 대한 얘기를 중점적으로 오늘 해보려고 한다.

오해와 사실

• 당신은 진정한 테스트 코드를 작성했는가? 당신의 테스트 코드는 이미 검증된 라이브러리를 테스팅 하고 있지는 않은가? 당신은 진정 코드라인을 격리(isolation) 시키고 라이브러리는 Mocking 하여 사용하는가? 당신의 테스트 코드는 Unit-Test 인가 E2E Test 인가를 잘 생각해봤으면 좋겠다.

• 테스트 커버리지가 제품의 신뢰도를 의미한다? 100% 로 짜면서 느낀점은 사실 제품의 신뢰도와는 큰 거리감이 있다고 생각한다. 테스트 코드는 테스트 케이스를 기반으로 작동하게 되는데 이는 그 logic 을 개발한 개발자 혹은 QA 팀에의해 작성되게 된다. 하지만 서비스 로직은 항상 예기치 못한 오류가 발생할 수 있고, 개발자가 생각하지 못한 Case 에 대한 오류도 발생할 수 있기에 테스트 커버리지가 100% 입니다! 라고 말해도 제품의 신뢰도가 100% 입니다 라고 말할 수 없다.😭

• 위의 목차와 같다면 왜 테스트 코드를 작성해야 하는가? 라는 생각을 했을때 내 답변은 아래와 같다. 점점 비대해지고 복잡해지는 비즈니스 로직이 작성되고 있는 회사라면, 핵심 로직을 변경하는데 당신을 신뢰할 수 있는가? 수정을 한번 하고 테스트 코드를 돌려본다면 우리는 우리가 설계한 테스트 케이스 안에서의 Side-Effect 는 체크해 볼 수 있을 것이다.✅

• 현재까지는 Test-Case, 즉 특정 경우에 대한 커버리지만 작성한다면 어플리케이션의 Flow 는 변함없이 잘 동작할것만 같다. 근데 테스트 커버리지 100% 를 달성하기 위해서는 각 라인에 대한 테스팅이 이루어져야 한다. 그렇게 되면 현재 Test 와 동일한 비용 혹은 더 많은 비용이 사용될 수 있다. 이렇게 해서 얻는 장점은 무엇일까..? 내 생각은 아래와 같다.

Test Coverage 100% 💯

• 테스트 코드 자체가 해당 로직의 SPEC 이 된다.🎉 이는 엄청난 장점이라고 생각한다. 요즘 같이 협업을 위한 문서화 혹은 처음온 신입에게는 Testing 되는 Case 만 보더라도, 이 로직이 어떤식으로 작동하고, 어떤 오류를 일으킬 수 있는지, 내가 어떤 코드를 작성하면 Side-Effect 를 일으킬 수 있는지를 한눈에 볼 수 있는 자료라고 생각한다. 이는 문서화 체계가 잡혀져 있지 않을 수록 테스트 페이지를 이용해 이를 대체해볼 방법을 고안해 보는것도 좋다고 생각된다. (물론 상황에 따라 다르며 100% 옳은 것은 없다! 회사의 상황과 개인의 상황을 고려하여 결정하는것이 중요!)

• 문서화의 강제성 또한 한몫을 한다고 본다. 만약 팀내에서 핵심로직은 테스트 커버리지 100%로 작성해보자 라고 규약을 정했고, CI 파이프라인에서 100%가 아니라면 통과가 안된다고 해보자, 해당 로직을 수정하거나 변경했다면 테스트 코드에 대한 수정 또는 변경이 거의 강제될 것이다. (어떤 Function 이 Call 됬는지도 테스팅 되고 있는 경우) 따라서 우리는 코드에 따라 동적으로 변하는 하나의 SPEC 문서를 가지고 있으며, 이는 강제적으로 작성되어야 하는 문서화가 되었음으로 항상 최신 수준의 문서임을 거의 항상 보장해준다고 볼 수 있을 것이다.

• 리팩토링의 두려움 상쇄 우리는 회사의 핵심 비즈니스 로직 혹은 회계 로직을 수정한다면.. 항상 두려움에 떤다.. 내가 작성한 코드가 Side-Effect 를 일으키지는 않을까? 이대로 배포해도될까? 라는 생각에 둘러싸여 코드를 작성하는데 자신감을 잃거나, 이 불안감으로 인해 종종 좌절하거나, 실수를 범하곤 한다. 하지만 코드의 변경 후 테스트 커버리지를 100%로 완성한다면 현재 로직에 대해 배포를 해도 상관없겠다는 자신감을 가질 수 있다. 자신이 수정한 로직에 대한 Test-Case 를 전부 작성했고, 라인에 대한 테스팅이 되므로! 이 부분이 상관 없는거 아닌가? 라고 생각하는 사람도 있겠지만 나 같은 경우 좀 이런 심적인 부분도 상당한 장점이라고 생각하기도 한다.

• 빠른 오류 해결 만약 서비스 로직에서 오류가 났다면 우리가 생각했던 테스트 케이스에 대한 오류가 아닐 것이므로, 해당 오류를 찾아서 수정한 뒤 수정한 내역에 대한 테스트 커버리지를 100%로 만든다면, 앞으로도 그 오류에 대한 방어율은 100%를 유지할 수 있을 것이다.

단점😭

• 위의 얘기만 들으면 항상 좋아보인다. 아니 물론 기술적으로는 아주 좋은 방법론이라고 생각한다. 하지만 회사의 경우는 항상 트레이드 오프(💰)라는게 기술적일 수 없다고 생각한다. 즉, 당신의 팀이 테스트 커버리지를 100%로 채우거나 테스트 코드를 작성하는 것이 현재 회사의 이윤 창출에 도움이 되는가? 를 중점적으로 생각해야 한다고 생각한다. 먼 미래에 힘들테니 테스트 코드를 작성하자 라는 말보다는 현재 상황이 테스트 코드를 작성하거나 리팩토링을 할 수 있을 정도의 여유라면 조금 씩 도입해보며 판단하는 것이 좋다고 생각한다. 그러다가 테스트 코드 작성 때문에 Product 개발이 망해버린다면 그 테스트 코드가 의미가 있는가? 기술적으론 좋지만 항상 현실과의 트레이드 오프를 잘 계산해야 한다. 맹목적인 테스트 코드 신봉론자는 오히려 테스트 코드에 대한 회의론자를 대거 생산해 낼 수 있다고 생각한다. 👻👻

끝맺음

• 개인적으로 사이드 프로젝트를 테스트 커버리지 100%를 작성하며 느낀점을 적어보았다. 사실 100%를 유지시키려면 엄청난 비용이 드는건 맞는 것 같다. 익숙해지면 빨라질 것 같기도 한데.. 아직은 초보 개발자이다 보니 격리시킨뒤 내 로직에 대한 테스트만 작성하는 것이 상당히 힘들었다. 다음 사이드 프로젝트는 루비 온 레일즈 혹은 자바 스프링 으로 할 것 같은데, 그때도 Jacoco 로 작성해 보아야 겠다.

• 초보 개발자의 느낀점 정도로 생각하고 봐주시면 감사하겠습니다. 틀린 의견에 대한 피드백은 항상 좋아하니 댓글로 남겨주시면 감사하겠습니다~~!😃😃