인프런 퇴근길 밋업 #05 백엔드 테스트 코드 후기

저번에 인프라를 주제로 한 인프런 퇴근길 밋업 포스팅을 올렸었는데

이번에는 "테스트코드"라는 너무 좋은 주제로 진행된다는 소식을 듣고 바로 신청을 했습니다 ㅎㅎ

총 60명을 추첨하여 밋업을 진행하는데 신청 당시만 해도 300명이 넘는 분들이 신청을 하셨어서

이번에는 좀 어려울 수도 있겠다... 싶었는데 운이 좋게도 60명 내에 선정됐다는 문자를 받았습니다!

( 최종 신청 인원은 480명이었다고 합니다...ㄷㄷ )

 

저는 평소 테스트코드의 중요성은 알고 있었지만 테스트코드를 작성 문화를 가진 팀에서 일한 경험이 없었고

항상 어느 범위까지 테스트코드를 짜야하고 의미있는 테스트를 하려면 어떻게 해야 하는지에 대한 갈증이 있었습니다.

이런 갈증들을 해소하고자 밋업에 신청하게 되었고 많은 인사이트를 얻어와서 이번에도 후기를 남기려 합니다.

 

밋업은 아래와 같은 순서로 진행되었습니다.

 

1. 테스트코드는 꼭 작성해야 할까?

첫번째 세션은 인프런 백엔드 팀에서 근무하시는 김명일 님이 위 주제로 진행해 주셨습니다.

 

테스트 코드의 필요성에 대해 이야기해 주셨고 테스트코드를 사용함으로써 얻을 수 있는 프로젝트의 생산성 향상과 안정성 보장 등의 장점들을 전달해 주셨습니다.

저도 테스트코드에 어느 정도 관심이 있었기 때문에 일반적인 장점들을 알고 있었는데 도식화된 그림을 통해 다시 한번 테스트코드의 중요성을 되새길 수 있었습니다.

2. 좋은 테스트 코드란 무엇일까?

이후에 좋은 테스트 코드에 대한 기준에 대해 말씀해 주셨는데

명일님이 생각하시는 좋은 테스트 코드란 아래 3가지 규칙을 지키는 테스트 코드라고 하셨습니다.

 

1. 빠른 실행

 

테스트코드의 실행은 항상 빨라야 합니다.

테스트코드가 무거워서 실행이 느려지게 되면 테스트코드를 돌리는 횟수가 줄어들게 되고 그러면 팀의 생산성 저하뿐만 아니라 에러 감지 능력도 저하되는 점을 경고하셨습니다.

 

빠른 테스트코드를 만들기 위해서는 작은 단위의 테스트인 Unit Test를 위주로 테스트코드를 구성하는 것이 좋음도 전달해 주셨습니다.

 

2. 쉽게 깨지지 않는 코드

 

쉽게 깨지는 코드란 상세 구현 사항을 타깃 하는 테스트코드를 의미합니다.

대표적인 예시로 임의의 객체를 생성하여 실제 객체를 대체하는 테스트더블(test double)이 있는데 이러한 부분들은 사용하는 함수가 변경되는 등의 간단한 수정만 일어나도 실제 동작은 정상이지만 테스트 자체가 실패해 버리는 부작용을 말씀해 주셨습니다.

 

그래서 테스트코드는 비즈니스 로직의 상세 구현이 아닌 결과, 즉 해당 로직이 수행하고자 하는 목표를 테스트해야 함을 강조해 주셨습니다.

 

3. 회귀 방지

 

회귀 방지란 테스트가 얼마나 버그의 존재를 잘 나타내는지에 대한 척도입니다.

테스트 코드가 넓은 범위의 에러를 캐치할 수 있도록 해피케이스뿐만 아니라 에러케이스 또한 적절하게 테스트 시나리오에 포함시키는 테스트 코드가 좋은 테스트코드라고 전해주셨습니다.

 

말씀해 주신 내용을 정리해 보면 좋은 테스트 코드란 실행이 빠르면서 코드의 상세 구현이 아닌 목표만을 정확히 판단하고 다양한 에러 케이스를 검사할 수 있는 테스트코드가 좋은 테스트 코드라고 이해했습니다.

 

첫 번째 세션을 마무리해주시면서 현업에서 테스트 코드를 적용할 때 단위 테스트와 통합 테스트의 선택에 있어서 Trade Off를 고려하는 사례를 말씀해 주셨는데 결론적으로 단위테스트는 속도가 빠르고 통합테스트는 테스트할 수 있는 범위가 넓기 때문에 범위와 비중을 잘 고려하여 적절한 테스트 방법으로 분리하는 것이 좋다는 점을 전달해 주셨습니다.

 

3. 인프런에서 테스트코드를 적용한 방법

쉬는 시간 이후 이어진 두 번째 세션에서는 마찬가지로 인프런 백엔드 팀에서 근무하시는 김학산 님께서 현실적인 테스트 코드 적용에 대해 말씀해 주셨습니다.

 

Unit Test라는 책의 내용을 기반으로 발표를 진행해 주셨고 Mocking이 필요한 때는 언제이고 또 하지 말아야 할 때는 언제인지 말씀해 주신 부분이 정말 도움이 많이 되었습니다.

 

테스트 코드를 자다 보면 의존성을 가진 부분이 분명히 존재하는데

의존성의 타입을 아래 3가지로 나누어 설명해 주셨습니다.

 

• 관리 의존성

관리 의존성이란 내부 시스템이 아닌 외부 시스템이지만 내부에서 접근하는 것을 제외한 모든 접근이 차단된 private 한 상태이며 그로 인해 내부적으로 완전히 제어가 가능한 상태의 의존성을 의미합니다.

대표적으로 Database가 그 예시이며 이 경우에는 개발자가 모든 것에 대한 제어가 가능하기 때문에 최대한 Mocking을 하지 않는 것이 좋다고 전달해 주셨습니다.

• 비공개 의존성

비공개 의존성이란 내부에서 개발되진 않았지만 내부 시스템에 포함된 라이브러리 등을 의미합니다. 예시로 crypto와 같은 암호화 라이브러리를 생각하면 되는데 사실상 이러한 라이브러리들도 내부적으로 제어가 가능하며 private 하게 내부 시스템에 종속되어 있기 때문에 따로 Mocking을 하지 않고 랜덤 한 데이터들로 엣지케이스를 검증하는 것이 좋다고 전달해 주셨습니다.

• 비관리 의존성

비관리 의존성이란 외부 시스템을 의미하며 내부에서 관리할 수 없는 의존성입니다. 예시로 Sendgrid와 같은 메일 서비스를 생각할 수 있으며 이러한 서비스는 외부 서비스에 장애가 발생할 경우 내부 테스팅에 문제가 발생하므로 필수적으로 Mocking이 수행돼야 함을 강조해 주셨습니다.

 

저는 테스트코드를 작성하면서 Mocking은 대체 언제 해야 하는 거지? 에 대한 의문이 있었는데

위 내용으로 완전히 정리할 수 있었습니다.

 

이외에도 인프런에서 어떻게 테스트코드를 작성하고 계신지 등의 내용이 있었습니다.

 

4. 향로님과 함께하는 QA 시간

쉬는 시간을 잠시 가지면서 QA 준비를 해주셨는데 의자를 3개 준비하실길래 설마!? 했는데

정말로 향로님께서 QA 시간에 참가를 해주셨습니다.

유튜브로 자주 뵙던 분이라 신기하고 반가웠는데 무엇보다 QA를 진행해 주시면서 질문자 분들의 질문 핵심을 딱딱 정리해 주시고 내용을 바로바로 파악하시는 게 정말 저런 식으로 사고를 해야 빠르게 성장할 수 있겠구나를 바로 느낄 수 있었습니다.

 

인상적이었던 질문 중에 저랑 마찬가지로 테스트코드는 항상 통과되는 것을 목적으로 작성하기 때문에 이게 의미가 있는 건지 모르겠다.라는 질문이 있었는데 테스트코드는 발생할 수 있는 예외 케이스들을 정상적으로 검증할 수 있는지에 대한 목적을 두며 코드에 변경이 일어날 경우 프로젝트가 안정적으로 동작하는지에 대한 안전장치입니다. 테스트 시나리오를 생각하면서 발생할 수 있는 문제들을 인지할 수 있고 이는 프로젝트 설계뿐만 아니라 코드 품질을 개선할 수 있는 효과를 가져온다고 답변해 주셨습니다.

 

또 테스트코드를 작성하면 개발하면서 Swagger나 Postman 같은 툴을 안 쓰시냐는 질문도 있었는데

거의 안 쓰신다고 답변해 주신 것이 충격이었습니다.

저는 너무 애용하고 있는 툴들이었고 이런 툴 없이 테스트코드만으로 완전히 대체가 가능하다는 부분에 놀랐습니다.

저도 테스트코드를 능숙하게 작성하여 테스트 자동화를 시켜야겠다는 다짐을 하게 되었습니다.

 

5. 후기

인프런 퇴근길 밋업은 항상 최고인 것 같습니다.

선정해 주시는 주제도 너무 좋고 세션 내용까지 이렇게 좋은데 무료라는 점이...

솔직히 돈을 어느 정도 지불하더라도 들을 것 같습니다.

 

이번 밋업을 계기로 테스트코드의 중요성을 다시 한번 느꼈고 평소 테스트 코드를 작성하는 습관을 들여야겠다고 다짐했습니다.

세션을 진행해 주신 분들 모두 저랑 비슷한 나이대로 보이셨는데 정말 많이 고민하고 노력하신 것이 눈에 보여서 자극도 많이 되었던 시간이었습니다.

 

저도 테스트코드 작성하는 습관을 들이고 역량을 키워놓고 언젠가는 인프런과 같이 테스트코드 작성 문화를 가진 조직에서 일해보고 싶다는 생각이 들었습니다.