인프콘에서 발표를 하고 현장에 계셨던 분들이 어떤 느낌을 받았는지, 어떤 것들을 배웠고 어떤 것들은 아쉬웠는지 피드백을 받고 싶어졌습니다. 그래서 인프콘 후기를 검색해 보며 발표와 관련된 피드백들을 몇 가지 확인해 볼 수 있었습니다. 재미있었다는 반응이 의외로 많았고 잊고 있었던 기본적인 것들을 다시 상기한 시간이었다는 긍정적인 반응과 기술적인 내용을 기대하고 들어갔는데 테스트에 대한 마인드셋이나 방법론적인 내용이 주를 이뤄서 아쉬웠다는 평도 많았습니다. 그 중에 아래와 같은 내용의 아쉬운점을 말씀해 주신 분의 글을 만나게 되었는데 저도 공감이 되고 발표에서 설명이 부족했다는 느낌이 들어 설명을 조금 더 정리해 보았습니다.
발표자분이 PM 이시기 때문에 사용자 스토리 기반의 테스트를 하는게 아닌가요? 개발자의 단위테스트에 적용하기 적절한가요?
1. 사용자에 대한 정의
우선 제가 발표에서 ‘사용자’라고 지칭한 부분은 발표를 들으시는 각자의 역할에 따라 달리 해석해도 좋을 것 같습니다. PM, PO 역할이라면 제품 전체를 책임지고 있으니 최종 사용자를 상상할 수 있겠고, 서버 개발자라면 서버 파트를 책임지고 있으니 나에게 요청을 하는 UI 파트나 또 다른 서버 파트를 ‘사용자’로 상상할 수 있을 것 같습니다. 요지는 내가 책임지고 있는 부분(작은 부분일 지라도)에 ‘어떤 요청을 가하고 내가 응답해야 하는 외부 대상’을 사용자로 보고 저는 설명을 했습니다. 다만 발표에 이 점을 분명히 밝히지 못했던 것 같고, UI 파트 예시만 들고 제가 PM 역할이란 설명을 하다보니 말씀하신 오해를 할 수 있을 것 같습니다. 제가 설명드린 7가지를 그대로 API 서버 개발자의 단위테스트에 다음과 같이 적용할 수 있을 것 같습니다.
2. API 서버 단위테스트에 적용
테스트 케이스
API 서버 개발자 역시 하나의 기능을 개발하고 테스트할 때 어떤 조건에서 어떤 입력을 가했을 때 어떤 결과를 기대하는지 테스트 케이스를 미리 이해하고 테스트를 진행해야 한다고 생각합니다. (사실 미리 이해하고 개발을 해야 겠죠) 여기서 어떤 입력은 제품 사용자가 아니라 UI 파트 또는 다른 API 서버가 하는 입력이 될 수 있겠죠.
제품 요구사항
테스트 케이스 작성을 위해서는 PM 이나 UI 개발자가 아니더라도 사용자 관점의 제품 요구사항을 이해하고 전체 안에서 내가 맡은 부분적인 역할, 즉 다른 파트에서 내게 요청하고 있는 또 다른 작은 요구사항을 잘 이해해야 한다고 생각합니다. 발표에서 UI 파트를 예로 들다보니 제품 요구사항과 내가 개발하는 부분적인 역할 안에서 이해할 요구사항이 유사해서 더 오해를 부른 것 같습니다.
(외부) 인터페이스
그리고 서버 파트 단위테스트 중 문제가 발견되면 외부 대상과의 인터페이스를 찾고 그 안에서 요청하고 응답하는 메시지들을 흐름을 따라 확인하는 일이 선행되면 문제 원인을 팀 안에서 조금더 효율적으로 찾아 갈 수 있는 것 같습니다. 발표에서 예로 든 저희 시스템이라면 서버 개발자는 UI 파트 그리고 하드웨어 API 서버와의 인터페이스를 확인해야 합니다.
처음 만나는 프로덕트
그리고 API 서버 개발자 역시 개발 단계에 부분적으로 만나던 제품을 테스트 단계에 완성되고 통합된 형태로 처음 마주하게 되는 것 같습니다. 그래서 나에게 요청을 하는 사용자 입장으로 API를 직접 호출해 볼 수 있는 지금 시점에 API를 호출해 볼 수 없었던 분석 단계에 정의한 요구사항에 부족한 것은 없는지, 개선할 것은 없는지 확인해 볼 수 있는 절호의 찬스인 것 같습니다.
사용자
API가 어떤 부분이 불편하고 좀더 개선되면 좋은지는 사용자 관점(여기서 역시 제품 사용자가 아니라, 나의 API를 직접 호출하는 UI 파트나 또다른 API 서버가 되겠죠)에서 생각되어야 할 텐데 사용자가 내 API를 사용하며 겪게 될 상황을 상상해 보고 내 API는 그걸 잘 돕고 있는지 비교해 볼 수 있겠고, 그리고 똑같은 기능이더라도 좀더 편하게 API를 사용할 수 있는 방법도 잠깐 고민해 볼 수 있을 것 같습니다.
일관성
뿐만 아니라 테스트 단계에 여러 API 들이 일관된 패턴을 가지고 사용자(개발자 동료)가 쉽게 익숙해 질 수 있도록 개발되었는지 리뷰해 보기 좋다고 생각하구요.
테스트 합시다!
마지막으로 테스트를 SKIP 하고 싶은 악마의 유혹을 서버 개발자 역시 느낄 때가 있는 것 같습니다. 내가 작성한 코드가 너무 간단한 코드일 때, 또는 하드웨어가 설치되어 있어야만 테스트가 된다던지, 다른 종속성 있는 모듈과 연동이 어려운 경우 순간적인 유혹을 받을 때가 있는 것 같습니다.
발표를 마치며
결론적으로 서버 개발자도 API를 사용하는 사용자를 진심으로 생각하고 작은 배려를 해 본다면 UI개발자가 혹은 다른 API 서버 개발자가 여러분의 API 서비스를 더 사랑하게 되지 않을까 생각해 봅니다.
3. 코드로 테스트 케이스 작성
글을 정리하다 보니 코드로 자동화된 테스트 케이스를 작성하는 것과 관련된 부분도 조금 부연 설명하고 싶어져서 짧게 남겨봅니다.
테스트 케이스
코드로 자동화된 테스트 케이스를 작성할 때에도 역시 어떤 조건에서 어떤 입력을 가할 때 어떤 결과를 기대하는지 먼저 이해하고 코드를 작성해야 합니다.
제품 요구사항
코드로 테스트 케이스를 작성하려는 노력을 하는 순간 자연스레 요구사항을 구체화해서 바르게 이해하려는 노력을 하지 않을 수 없게 됩니다. 왜냐하면 구체화 하지 않으면 코드를 작성할 수가 없거든요. 그래서 사실 실패하는 테스트 코드를 먼저 작성하는 TDD를 사용하면 요구사항을 코드 작성 전에 구체화해서 이해하게 되는 장점이 있고 그래서 개발을 더 잘하게 되는 효과가 있는 것 같습니다.
(외부) 인터페이스
그리고 테스트케이스 작성 시에도 내부 구현에 대한 테스트 코드를 작성할 때도 있지만 가장 필수적이고 기본적인 것은 내가 개발하고 있는 컴포넌트의 인터페이스를 확인하는 테스트 코드를 먼저 작성하는 것이 중요한 것 같습니다.
사용자
그리고 구현 이후 그리고 릴리즈 이전 테스트 코드를 작성하기 시작하면 내가 처음 사용자가 되어보는 효과가 있습니다. 그래서 API의 버그 뿐 아니라 불편한점 일관성을 해치는 점 등을 쉽게 발견하고 개선해 나갈 수 있는 것 같습니다.
4. 글을 마치며
발표가 한 사람에게라도 유익하고 또한 재미있으면 좋겠다는 생각을 하면서 2달 동안 발표자료를 준비했는데 긍정적인 피드백을 보니 뿌듯한 마음이 듭니다. 반면에 자동화된 테스트 케이스를 코드로 작성하는 기술적인 내용을 기대하며 오셨던 분들에게는 발표 소개에 좀더 분명히 명시해 드리지 못해 죄송한 마음이 듭니다. 마지막으로 위에 보충 설명을 한 것 처럼 제가 소개해 드린 7가지는 PO, PM이 해야할 일을 염두에 두고 설명하지 않았습니다. 사실 ‘더 나아가면 좋은 3가지’ 부분은 누구나 그리고 항상 해야하는 일이라고 생각하진 않고 (상황이 허락된다면) 실천해 본다면 제품 개선에 도움이 될 거라 생각해서 정리해 보았습니다. 발표 들어주시고 글도 읽어 주셔서 감사합니다 : )
📌 발표영상(유튜브)
📌 발표자료
📌 블로그원문
📌 발표를 준비하며 도움받은 7가지
