구글 엔지니어는 이렇게 일한다 #11장 테스트 개요를 읽고

#11 테스트 개요

| 일부 내용
최고의 팀은 팀원들의 집단 지성을 팀 전체의 이익을 환원하는 방법을 찾아냅니다. 바로 자동 테스트가 하는일이죠.

 

어쩌면 단순하다고 볼 수 있는 테스트 케이스 작성을 이런 관점에서 생각해볼 수 있다는것이 놀랍다.

 

---

 

| 일부 내용
더 나아가 하루에도 몇 번씩 새로운 버전을 릴리스해야 합죠. 일 년에 고작 한두 번만 업데이트되던 과거의 소프트웨어 세상과는 완전 딴판 입니다.

 

애자일, 스프린트 방식이 전반적으로 도입되기 시작하면서 프로그램의 배포주기는 더욱 더 짧아지기 시작하는것 같다. 

그만큼 배포, 롤백, 각종 트러블 슈팅의 빈도 수도 올라갔기 때문에 테스트의 중요성이 더 대두된다.

 

---

 

| 일부 내용
테스트 문화가 확실하게 뿌리 내린 조직을 경험해보지 못한 개발자는 테스트를 작성하면 생산 성과 속도가 높아진다고는 생각하기 어려울 것입니다. 오히려 반대로 생각할 가능성도 크죠. 어쨌든 처음에는 기능 구현에 드는 시간만큼을 혹은 그 이상을 테스트 작성에 써야 하니까요. 하지만 구글은 테스트에 투자하는 게 개발자 생산성 향상시키는 중요한 이유를 몇 가지 발견했습니다.

 

나도 개발을 처음 접하는 과정에서는 테스트 코드의 존재를 알지 못했을뿐더러 프로젝트를 진행할때도 "써야한다니까" 의식적으로 썼었다.

하지만, 신입 개발자로 취업을 하고 현업을 경험하면서 스프린트 방식 ( 2주 간격으로 배포 ) 으로 프로젝트를 진행하며 테스트 코드 작성으로 인한 심리적 / 실질적 안정감을 경험하고 나서는 테스트 코드를 작성하는 이유에 대해서 인식하게 되는 계기가 되었다.

 

추가로 책에서는 1) 디버깅 감소, 2) 자신 있게 변경, 3) 더 나은 문서자료, 4) 더 단순한 리뷰, 5) 사려 깊은 설계, 6) 고품질의 릴리스를 빠르게 총 6가지를 이유로 들었다.

 

테스트 코드를 업무에 적용하여 사용하게 되면 깊이 공감되는 내용들이다. 특히, 테스트 코드 작성을 위한 코드간 의존성을 의도적으로 나누는 경우도 있고, PR 을 리뷰하면서 테스트 코드를 통해 해당 코드 작업의 컨텍스트를 먼저 파악하는 경우도 있다.