구글은 엔지니어는 이렇게 일한다 - 테스트편

요즘 '구글 엔지니어는 이렇게 일한다' 많이들 읽으시죠? 저도 느리지만 회사 동료분들이랑 매주 조금씩 읽으며 생각을 나누는 모임을 가지고 있습니다. (재밌게도 모두 다른 직군: Backend, Frontend, DevOps, TPM) 최근에는 테스트에 대해서 다룬 11~14장을 읽었는데 테스트에 대해서만 다루는 웬만한 전문 서적들보다 내용이 알차다고 느꼈습니다. 책에서 읽은 인상 깊었던 내용과 거기에 대한 동료들 의견도 정리해보았습니다. 📝 구글은 '상호작용 검증' 보다는 '상태 검증'에 집중한다. 내부 동작을 가정하고 Mock 객체를 남발하는 상호작용 검증의 경우 깨지기 쉽다. 💬 가끔 Mock 객체가 가득한 테스트를 작성하면서 이게 무슨 의미가 있나 생각했는데 답답함이 해소된 기분. 이상한 건 이상한게 맞다~ 📝 테스트는 결정적이어야 한다. 불규칙한 테스트 실패 확률이 1%에 이르면 테스트의 가치가 바래지기 시작. 구글은 0.15% 정도를 맞추고 있는데 그럼에도 매일 수천 개가 실패한다. 💬 우리도 가끔 랜덤 실패 테스트 원인 찾는다고 괴로운데 구글도 그런다니 괜히 편안. 💬 예전에 OO님이 뜬금없이 통합 테스트를 넣은 적이 있었는데 너무 랜덤하게 실패를 자주해서 결국 빼버렸던 생각이 난다. 📝 테스트의 크기(size)와 범위(scope)는 다른 개념이다. 작은 크기의 테스트는 하나의 프로세스나 쓰레드 안에서 실행 되는 테스트이고, 큰 크기의 테스트는 네트워크 레이어를 넘어 여러 머신들을 통해 실행되는 테스트이다. 작은 범위의 테스트는 독립된 클래스나 컴포넌트 하나를 검증하고, 넓은 범위의 테스트는 여러 시스템이 조합되고 상호작용 할 때의 로직을 검증한다. 구글은 테스트의 결정성을 높히기 위해 작고, 좁은 범위의 테스트를 많이 작성하는 것을 추구한다. 구글은 유닛 테스트, 통합 테스트와 같은 용어를 사용하지 않는다. 💬 유닛 테스트, 통합 테스트 억지로 구분하려고 하다보니 헷갈렸는데 명확해졌다. 📝 구글은 테스트를 강제하지 않았다. 훌륭한 생각은 반드시 퍼져 나갈 것임을 믿으며, 테스트가 이롭다는 생각을 스스로 받아들이고 나면 아무도 강요하지 않더라도 계속할 가능성이 크다. 오리엔테이션 수업 때 신규입사자에게 테스트에 대해서 교육하고, 테스트 인증 제도를 만들고, 화장실에서 테스트(TotT)라는 참신한 활동을 통해 자연스레 받아지게 하였다. 💬 PUBG 프론트엔드 팀도 신입분들 데리고 테스트 도입을 시작해보는 중. 확실히 서서히 퍼져나가는게 좋은 전략 같다. 💬 카카오에서 온보딩이 끝나고 "비록 여러분의 팀은 이런 문화가 아닐 수도 있지만 실망하지말고 열심히 퍼뜨려서주세요"라는 말을 들은게 생각난다. 📝 테스트는 가능한 명확하게 작성하기 위해 DRY 원칙을 깨는게 좋을 때도 많다. 무엇을 테스트하는지, 실패 원인인지 엔지니어가 곧바로 알아차릴 수 있게하는 것이 더 중요하다. DRY가 아니라 DAMP(Descriptive And Meaningful Phrase) 💬 DRY 했던 나, 반성한다. 테스트에 로직을 넣지 말라는 말도 공감이 되었다. 🤷‍♂️ (토론) 왜 보통의 IT 회사에선 테스트를 성공적으로 도입하는 사례를 보기 힘들까? 💬 경험해보지 못한 것에 대한 부정적인 생각. 단순히 코드 작성량이 더 많아지니 더 작업 속도가 느려질 것이란 막연한 생각. 이것을 깨려면 구글의 사례처럼 이것이 결과적으로 더 빠른 길이라는 것을 스스로 느껴야함. 💬 결국엔 테스트 코드만 돌렸더니 내가 짠 코드의 예상치 못한 문제가 발견되는 'aha moment'가 존재해야지 확실히 와닿는 것 같다. 💬 다들 경험이 없으면 도입하고 삽질하는 과정에서 "역시 테스트 작성하는 건 별 도움이 안돼" 라고 부정적인 경험만 할 가능성이 높은 것 같은 것 같다. 💬 이를테면 typescript orm인 prisma는 unittest 예제로 모든 동작을 모조리 mock하는 것을 공식문서에 써뒀는데 이런 테스트는 해서 작성해서 뭐하나 싶은 생각이 들게 한다. 💬 돌이켜보면 PUBG 플랫폼의 테스트코드엔 mockist과 classicist가 짠 것이 섞여있다. 테스트작성에 경험이 많은 리드가 있었다면 초기부터 우리의 테스트 코드의 방향성은 어때야한다고 길을 잡아줄 수 있지 않았을까? (그래도 다들 열심히 짠게 어디야...)