이펙티브 소프트웨어 테스팅

 

테스팅 책을 읽은 이유

프로젝트를 진행하는 과정에서 테스트 코드의 필요성을 절실히 느꼈다.

코드를 봐줄 상급자가 없거나, 같이 리뷰할 팀원들이 부족하다면 에러가 안 나도록 기도 메타로 가야 했다.

그러다 보니 프런트 개발자와 API를 맞추는 과정에서 에러가 자주 발생했고, 그때마다 새로 배포를 하는 불편함이 있었다.

이를 해결하기 위해 단위 테스트 등을 통해 개발한 기능에 대한 테스트를 작성해 발생할 수 있는 위험성을 줄이고자 했다. 하지만, 통합 테스트같이 복잡한 테스팅이 필요한 경우를 만나니 테스트 코드 작성도 막막해져 책의 도움을 받고자 했다.

이 책을 선정한 이유

난이도가 적당했다.

아직 현업 경험이 없는 학생이다 보니, 전문 테스팅 책을 보는데 이해하기가 무척 어려웠다.

시간을 두고 읽으면 이해는 할 수 있다만, 프로젝트 일정이 빠듯했기 때문에 빠르게 읽고 적용해 볼 책이 필요했다. 이런저런 자료를 둘러본 결과 이 책이 현재 문제를 해결하기 적합한 책이라 생각했다.

간단한 CURD API 구현은 익숙하지만, 테스팅에 대해 지엽적으로만 알고 있다면 이 책이 큰 도움이 될 것이다.

뭐가 나아졌나?

테스트 코드에 대한 강박이 사라졌다.

테스트는 반드시 given, when, then으로 하고, 한 테스트당 하나의 then만 있어야 한단 강박이 있었다.

그러다 보니 내가 테스트를 만드는 건지 테스트를 위한 테스트를 만드는 건지란 의문이 들었다.

이 책은 형식보단 테스트에 집중한 코드들을 보여준다. 우리가 접해왔던 형식이 아닌 경우들도 있지만, 나는 오히려 이렇게 작성된 것이 더 보기 편했다.

지금도 given, when, then 을 맞춰서 하지만, 이제는 상황에 맞춰 이 틀을 깨는 것에 주저함이 없어졌다.

 

테스트를 구체적으로 구분할 수 있다.

그동안 테스트를 통합 테스트, 인수 테스트같이 큰 틀에서만 알았지 세부 상황에 대해선 잘 몰랐다.

이 책에선 그 세부 사항에서 각각 어떤 용어들이 있는지를 설명하고 잘 정리해 주고 있다. 그 덕에, 복잡한 테스트 환경에서 어떤 것이 필요한지 인지할 수 있게 됐다.

이것이 전문 용어를 섞어가며 의사소통할 수 있단 것은 아니다. 테스트에 잘 모르는 팀원이라도 필요해 보이는 요소를 집어 보완해 줄 수 있단 것이라 보면 될 것 같다.

마치면서

그동안 막연하고, 지엽적으로만 알던 TDD에 눈이 좀 트인 것 같다.

지금 쓰는 스택도 제대로 모르고 쓰는 거 같은데 TDD란 새로운 분야까지 알아야 했나? 란 생각도 많이 했지만 책을 읽으면서 생각보다 이런 걱정이 사소한 우려였단 것을 알게 됐다.

검색을 하기엔 지엽적인 자료들만 보이고, 강의를 사서 보자니 뭘 살지 애매하다면 이 책으로 시작을 해보는 것도 꽤 좋다고 생각한다.