테스트도 결국 좋은 애플리케이션을 만들기 위한 과정인 것 (레벨 테스트 10일차 작업 회고)

 

3주 동안 풀스택 개발과 레벨 테스트로 이어졌던 규모와 순서를 갖춘 하나의 작은 '프로젝트' 과정을 경험하는 예행 연습이 끝났다. 인수 테스트 작성이 동료들보다 늦어 일과가 끝난 뒤 1시간여 정도까지의 시간을 더 투자해 부족하나마 인수 테스트까지 모두 작성을 마쳤다. 기능은 모두가 똑같이 잘 구현할 수 있었지만, 제한 시간 내에 모든 것을 완전히 끝내지 못했다는 사실은 가슴 한 켠에 또 한번의 작은 아쉬움으로 남을 듯 하다.

사실 인수 테스트는 프로젝트를 시작하면서 의욕 충만하게 작성하기 시작했었던 부분이였다. 인수 테스트를 통해 프로그램이 처하는 대부분의 상황을 먼저 파악한 뒤, 그 상황들을 하나씩 케어해나가야 할 것이라고 생각했다. 그러다보니 프로젝트 초기에 요구사항을 보면서 인수 테스트 목록과 인수 테스트의 내용을 굉장히 빡빡하게 작성했었다.

인수 테스트에서 동작이나 생각할 수 있는 대부분의 예외 상황을 낱낱이 구체적으로 작성했으니까 구현도 그에 맞춰서 따라가기만 하면 되지 않을까 생각했었다. 하지만 꼭 그렇게 되지 않았다. 인수 테스트로 동작의 개괄은 나타낼 수 있었지만, 프론트엔드에서 구체적으로 상태를 어떻게 관리하고, 요청을 어떻게 주고, 백엔드에서 처리는 어떻게 할 것인지는 결국 또 다른 생각을 해야 하는 영역이었다. 결과적으로 그렇게까지 깊게 안 봐도 될 부분들을 너무 깊고 세세하게 파느라 다른 곳에 써야 할 시간을 가져와 쓰면서도 진행도에 탁월한 영향은 주지 못한 모양새가 되었다.

 

 

이 점이 크게 다가왔던 부분이 오후 시간에 있었던 레벨 테스트 과제 시연 때와 동료분이 올린 TIL 글을 보면서였다. 동료분의 인수 테스트 코드를 보았는데, 어떤 테스트를 할 때 정말 필요한 부분만을 확인하는 것 같았다.

 

다른 동료분은 아샬님이 테스트에 관해 설명한 영상을 보고 느낀 점을 정리해주셨었다. 글을 읽으면서 느낀 점은, 테스트 코드를 만드는 목적은 결국 좋고 검증할 수 있는 애플리케이션을 만들도록 유도하는 것이지, 토씨 하나 빼먹지 않은 완전한 테스트 코드를 만드는 것을 목적으로 테스트 코드를 짜서는 주객이 전도되는 것이겠구나 싶었다.

 

 

테스트를 이용해 내가 편히 갈 수 있어야지, 내가 테스트를 영차 끌고 가는 모양새는 곤란하다...

 

 

테스트 코드를 짤 때 지나치게 밀도 높고 빡빡하게 작성하기보다는, 해당 컴포넌트의 테스트에서는 무엇에 집중해야 하는지, 해당 인수 테스트에서는 사용자 가치를 만족시키기 위해 어떤 부분을 봐야 하는지, 특정 백엔드의 레이어에서 어떤 동작에 집중해야 하는지를 생각한다면 테스트 작성에 들이는 시간을 줄이면서도 오히려 더 효과적인 테스트를 작성할 수 있지 않을까 생각해본다.