[테스트 작성 시점] 기능이 어느 정도 구체화 되고 난 후 커버리지를 올린다 vs 기능이 추가될 때마다 그때 그때 테스트를 작성한다.

[Libienz]

테스트 작성은 귀찮다 🥲
사실 기능을 추가하면서 깨지는 테스트를 수정하는 쪽이 더 귀찮다고 볼 수 있겠다.

빠르고 애자일한 개발을 지향한다면 기능을 최우선으로 두고 테스트는 후에 커버리지를 올리는쪽으로 동료들과 합의할 수도 있을 것 같다.
반면에 누군가는 테스트는 기능 안전성 측면에서 기능이 추가될 때마다 바로바로 추가되어야 한다고 할 수도 있겠다.

물론 여러가지 벡터가 이와 같은 결정에 영향을 미치겠지만 기본적인 여러분들의 마음가짐이 궁금하다.

여러분들의 선택은 어느쪽인가?

• 테스트 없이 기능을 추가하고 후에 테스트 커버리지를 올린다.
• 기능을 추가할 때마다 테스트를 작성한다.

[Libienz]

리비 발제 의도

팀 프로젝트에 돌입하면서 다음의 두가지 의견이 충돌하는 경험이 있었다.

1. 기능 구현이 우선인 만큼 테스트 코드를 후순위로 두고 기능들의 구현이 어느정도 굳어졌을 때 테스트를 작성한다.
2. 테스트 코드의 신뢰성과 안전성을 높게 평가하여 기능 구현할 때마다 테스트 코드를 작성한다.

여러분은 어떤 쪽 인지 궁금하다.

리비 의견: 어느 정도 요구사항이 굳고 난 후 테스트를 작성한다.

서비스 초기 단계에서는 특히나 요구사항 변경이 잦음. 나의 프로젝트에서는 테스트 코드를 미리미리, 그리고 꼼꼼히 짜서 현재 돌아가는 테스트 코드가 270개정도임. 이렇게 되니 요구사항이 변경될 때마다 프로덕션 코드보다 테스트 코드를 고치고 있는 시간이 훨씬 길다. 프로덕션 고치는 것은 3줄 정도 고치는데, 테스트 코드는 수십개를 고쳐야했던 적도 있음. 개발 생산성이 떨어지는 부분이라고 생각했고, 테스트 코드를 후술하는 것이 좋을 수도 있다고 느끼게 되었다.

제리 의견: 작성한 기능의 테스트 코드는 당시에 존재해야 한다.

마음가짐의 문제도 있다고 생각한다. 나중에 쓸꺼니까~라고 생각하고 나중에 쓰지 않았던 경험도 있는데 그렇기 때문에 의식적으로라도 테스트 코드를 그 때 그 때 작성하는 것이 중요하다고 생각.

코드의 신뢰성 측면에서 테스트 코드를 논할 때 누군가는 테스트 코드 없이 QA�를 믿으면 되지 않냐?라고 말할 수도 있겠다. 다만 본인은 QA로 모든 시나리오가 검증될 것이라고 생각하는 것이 naive하다고 생각. 개발자가 코드의 동작을 언제든지 검증할 수 있어야 한다고 생각한다. 테스트 코드는 한번 작성하면 언제든지 코드의 동작을 검증할 수 있다. QA 기간에만 검증한다면 그건 상당히 위험한 프로젝트라고 생각!

콜리 의견: 작성한 기능의 테스트 코드는 당시에 존재해야 한다.

당연하게도 테스트 코드를 통한 확신은 필요하다. 다만 제한 시간이 한정되어 있는 상황에서 리소스를 어디에 더 많이 투입을 해야 하냐라고 묻는 다면 테스트 코드 보다는 프로덕션 코드라고 대답할 것이다. 그럼에도 테스트 코드가 기능이 추가될 때마다 존재해야 한다고 생각하는 이유는 장기적인 관점으로 보았을 때 테스트 코드가 있는 쪽이 생산성이 더 좋다고 믿기 때문.

브랜치 관점에서 테스트 전략을 생각해보자.

리비: dev 브랜치와 prod 브랜치를 많이들 운용하고 있는 것으로 안다. dev 브랜치는 테스트 없이 빠르게 기능을 머지하고 prod 브랜치로 배포하기 전 테스트 커버리지를 올리는 전략을 어떻게 생각하는지?? 어느정도 구현이 굳고 테스트를 작성하기에 생산성이 올라갈 것으로 기대되는 것 같고 브랜치의 성격에도(dev는 기능 빠르게 구현, prod는 안전성 갖춘 상태로 배포) 잘 맞는 전략인 것 같다.

제리: 개발한 요구사항의 테스트에 대해 구현 당시에 테스트를 작성하는 쪽과 후에 작성하는 쪽을 비교해보면 후에 작성하는 쪽이 누락되는 테스트가 많을 것이라고 생각. 아무래도 기계적으로 테스트만 작성하다가 누락할 가능성이 크다고 생각한다. 더 나아가서 미리 작성한 테스트는 여러 번 수정되고 이를 리소스 낭비로 볼 수도 있다는 의견에는 동의함. 다만 테스트가 없다면 dev 브랜치 prod 브랜치를 떠나서 특정 브랜치로 merge되어 오는 코드를 뭘보고 믿어야 될 지 모르겠다. 테스트가 없다면 코드의 동작을 검증하기 위해서 postman등을 사용해 직접 api를 쏴볼 수 밖에 없다. 이러한 과정이 반복된다면 테스트 코드가 왜 필요한지를 알게 될 것이라고 생각한다. 테스트는 딸깍하면 검증되는 반면 postman은 그 과정이 훨씬 복잡하니.. 어짜피 작성되어야 하는 테스트 코드라면 수정의 공수가 있더라도 미리 작성하는 것이 좋다고 생각한다.

콜리: 테스트가 얼마나 촘촘하게 짜여져 있는가도 고려할만한 벡터라고 생각. 나의 프로젝트에서는 테스트 숫자도 그렇고 그 정밀함도 어느정도 타협했기에 테스트 수정 공수에 대해서는 리비만큼 공감가지 않는다. 중요한 점은 나는 타협을 할 거면 테스트를 작성하지 않는 쪽으로 타협하지는 않을 것 같다는 얘기다. 테스트를 느슨하게 작성하는 쪽으로 타협을 고민하겠지만 테스트를 아예 작성하지 않지는 않을 것 같다.

테스트 코드는 정말로 그 의미를 다하는가?

리비: 테스트 코드 있으면 좋은 거 물론 알고 있다. 하지만 그 정도로 좋은 지 모르겠다. 단순 json 상하차, 싱크홀 패턴에 대해 테스트를 작성하고 있자면 기계적인 단순 노동을 하고 있는 것 같은 기분이 든다. 그것도 요구사항이 변경되면 나중에 다시 마주해야 할 노동을.. 사실 지금 우리가 작성하고 있는 관습적인 레이어드 코드와 간단한 도메인 로직들이 테스트 코드가 필요한지 조차 의문이 들기 시작했다. 이전에 테스트 코드를 통해 잘못된 로직을 발견했던 긍정적 경험이 적기에 더욱 의심이 드는 것 같다. 어떻게 생각하는지??

제리: 소프트웨어 세계에서 아무리 쉬운 코드라도 검증이 의미없다고 생각하지는 않는다. 아무리 쉬운 코드라도 그 위에 복잡한 연관이 생겼을 때 촘촘히 짜여진 테스트 코드는 리팩터링 내성을 올려준다. (이 부분은 테스트를 통과하니까 다른 부분 문제네?) 하고 싶은 말은 검증이 의미없다고 생각하지는 않는 다는 것이다. 하지만 리비 말처럼 테스트로서의 그 의미가 어려운 로직에 대한 테스트 코드보다 적을 수는 있다고 생각한다.

콜리: 합리화를 조심해야 한다고 생각한다. 제리와 리비가 말했던 것처럼 간단한 로직에 대한 테스트의 의미는 복잡한 그것에 대해 적다고 생각한다. 하지만 로직이 간단하니까 테스트 코드를 작성하지 않고 마감기한을 맞춘다. 이와 같은 생각은 위험하지 않을까? 시간이 촉박하여 테스트 코드를 버리게 되었다는 그럴 듯하지만 시간이 촉박할 것 같으니 테스트 코드를 버리자는 개인적으로 합리화 하기 어려운 것 같다.

테스트 코드는 사실 협업에서도 큰 가치를 가진다.

제리: 사실 나는 안전성 보다 예전부터 테스트 코드의 진정한 가치는 협업에서 나타난다고 생각. 협업에서 동료의 코드가 그 기능을 다하는지는 동료가 작성한 테스트 코드를 확인해봄으로써 쉽게 파악할 수 있다. 테스트 코드가 없는 코드 리뷰는 그 힘듦이 배이상 차이난다고 생각한다. 또한 테스트 코드는 다른 사람이 구현한 코드를 신뢰성있게 이용하도록 도와준다. 분명 귀찮지만 테스트 코드는 많은 가치를 가지고 있다.

콜리: 동의한다. 코드리뷰에서 테스트 코드가 작성되어 있는 경우가 그 기능을 파악하기 훨씬 쉬웠다. 협업에서의 가치까지 판단한다면 테스트 코드에 드는 공수를 충분히 감수할 수 있다고 생각한다.

리비: 이 부분에는 동의한다. 나도 동료의 코드에 대한 신뢰를 동료가 작성한 테스트 코드로 부터 얻곤 했던 것 같다. 오늘 들었던 의견 중에 제일 많이 설득되었다.

토론 회고

리비: 사실 테스트 코드가 가치있고 필요하다는 것은 마음속으로 알고 있다. 다만 테스트 코드를 유지보수하는 공수와 얻게 되는 가치를 저울질 해보고 싶었고 오늘의 토론이 많은 귀감이 될 듯하다. 테스트 코드가 깨지면 Fixture, Helper등, 조금 더 우아한 방법을 고민해볼 수 있다고 생각한다. 테스트 코드의 가치를 되새기며 앞으로의 작업 진행하게 될 것 같다.

콜리: 테스트 정밀성에 대해서도 여러가지를 생각해보는 계기가 되었다. 정밀성과 테스트 코드 유지보수 사이의 트레이드 오프 지점을 인식하고 다양한 의견을 들을 수 있어 좋았다.

제리: 개발자들은 기한에 쫗기곤 한다. 그렇기에 선택을 해야하는 경우도 분명 존재한다. 하지만 확실한 저울질을 통해서 그것이 결정되어야 한다고 생각하고 테스트 코드는 내가 느끼기에 얻게 되는 베네핏이 훨씬 많았다. 생각을 다시 한 번 정리할 수 있는 기회가 되어 의미있었다.