테스트 레벨
말로만 테스트 테스트하지 말고
매주 수요일에 참치팀 스터디를 하고 있다.
https://github.com/orgs/teamtuna/people
요즘은 "구글 엔지니어는 이렇게 일한다."를 읽고 관련 주제를 토론하는 스터디를 진행 중인데
책 11~14 장에 나온 테스트에 대해서 토론하던 중, 각자가 생각하는 "테스트 레벨 정의해오기" 과제를 냈다.
그 후 1주일 다시 스터디 시간
각자가 생각하는 테스트에 대해서 발표하고 정리하는 시간을 갖었다.
테스트 레벨을 나누는 방식이라는 막연한 주제에 대해서 누구는 구성원의 스킬, 또 누구는 조직의 문화로 나누어서 정의해 왔다.
우리는 토론을 하면서 조직과 개인으로 나누어서 레벨을 나눠봤다.
개발자 Test Level
Level 1
단순한 Unit Test를 만들 수 있다.
Level 2
테스트 더블을 효과적으로 작성할 수 있다.
Level 3
테스트 기법을 안다. (비동기 테스트, 스레드 간 테스트 등...)
Level 4
테스트가 필요한 위치를 알고, 효과적으로 작성할 수 있어야 한다. (with TDD)
요구사항을 기반으로 테스트 케이스를 만들 수 있어야 한다.
테스트하려는 대상의 의존성 관리 설계를 할 수 있어야 한다. (아키텍처)
프로젝트(조직) Test Level
Level 0
테스트가 없거나, 있어도 관리가 안됨, 관심도 없음
향상 방향 → 테스트 코드에 관심
Level 1
개인 개발자의 의해 테스트 코드가 작성되거나, 테스트 코드가 없음, 관심은 있음
향상 방향 → 테스트 환경 설정(자동화), 테스트를 깨트리지 말아야 함, PR에서 테스트 코드가 리뷰를 진행
Level 2 (좋은 회사 - 노력할 수 있는 회사)
개발 프로세스에 테스트가 있음, CI/CD를 이용한 Unit Test, Test Coverage 정의가 있음
향상 방향 → 최소 커버리지를 갖추어야 함, 모든 구성원이 테스트 코드를 강제함(PR), 테스트 담당자
Level 3 (국내 Top tier)
테스트 기반의 설계, 리그리션 테스트를 할 수 있음
테스트를 리딩 할 수 있는 구성원이 있음 (개발자 Lv3)
향상 방향 → 각 구성원의 숙련도 향상
Level 4
모든 구성원이 테스트 케이스에 대한 높은 이해를 갖고 있음 (개발자 Lv3 이상)
향상 방향 → 평가 반영, TDD 설계 등 방법론에 대해 잘 이해
Level 5 (Google)
단위 테스트를 넘어 통합 테스트가 주기적으로 진행되며 테스트 기반 설계로 프로젝트를 수행함.
설계부터 구현까지 성과 평가에 반영(개발자 lv 4, ex: TDD 설계 등
우리가 스터디를 하면서 정리한 Test Level은 정답도 그렇다고 오답도 아닐 것이다.
테스트를 개인과 조직에 도입하기 위해서는 스스로의 상태를 알아야 다음 단계로 나아갈 수 있다.
15년 전에도 말로만 하던 테스트를 아직도 말로만 테스트해야지 하고 있다.
내년에는 부디 테스트 좀 잘했으면 좋겠다.
