[SpringCooler] Spring + DDD 스터디 2주차

이번 주 발표자는 나야 나

토비의 스프링 2장의 주제는 '테스트'입니다. 이 주제는 꼭 제가 발표해야겠다는 생각에 슬쩍 손을 들었습니다. 테스트라곤 다른 사람의 코드를 보고 떠듬떠듬 써본 게 전부인 제가 자진해서 발표를 맡은 이유는 이렇습니다.

 

저번 포스팅에서 DE-labtory 프로젝트 경험을 언급했었는데요, 이때 테스트 코드라는 걸 처음 접해보았습니다. 저로서는 대체 이게 어떻게 테스트를 해준다는 건지 이해가 되지 않았죠. 그래서 동료에게 '이게 정말 애플리케이션 코드랑 연동이 되어서 테스트를 해주는거냐' 같은 질문을 했더니 뭐 이런 걸 질문하냐는 듯이 황당한 표정을 짓더라구요, 하핫!

 

그만큼 테스트 코드라는 존재에 대해 무지했습니다. 컴퓨터가 자동으로 이렇게 똑똑한(?) 기능을 해줄지 상상도 못 했던 겁니다. 

 

 

테스트는 저에게 상상도 못한 정체였습니다

 

왜 굳이 테스트를?

다른 거 하기도 바쁜데 테스트 코드가 뭐길래 다들 해야한다고 난리일까요?

 

 

 

내가 짠 코드가 내일 안 바뀔 것이란 보장이 없기 때문입니다. 고객이 새로운 기능을 요청할 수도 있고 그냥 짜다보니 변경이 필요할 수도 있어요. 미래의 내가 X되지 않도록(...) 먼저 대비를 해놔야 합니다. 코드를 수정해도 테스트 코드를 한 번 거쳤다면 마음 놓고 배포할 수 있겠죠!

 

테스트 코드의 존재를 알기 전, 제가 테스트한 방법은 이랬습니다.

자 이제 테스트를 해볼까 → 결과를 봐야하니까 화면을 만들어야겠구나 → 입력할 폼이랑 저장할 객체도 필요하네 → 자 이제 진짜 테스트를 해볼까 → (에러 메시지 와장창) → 울면서 수정 → 값 하나 확인하려고 RUN만 몇 십번 반복 → 모든 과정 무한 반복

얼마나 번거롭고 귀찮은 일입니까. 심지어 그 과정에 로그인이 있다? 그럼 포스트맨으로 하나하나 토큰 넣어주면서 api 결과 확인해야 했습니다. 그렇게 미련하게 노가다한 것이 제가 아는 테스트의 전부였습니다. 그야말로 '삽질' 이었던 것이죠.

 

테스트 코드의 장점

테스트는 이러한 문제를 해결해줍니다. 장점을 정리해보자면 아래와 같습니다.

버그를 빨리 발견하고 수정할 수 있다

설레는 마음으로 RUN 버튼을 눌렀는데 에러가 쏟아져 나왔던 경험, 다들 있으시죠? 테스트 코드는 메소드 같은 작은 단위로 나눠서 진행하기 때문에 한꺼번에 버그가 몰려서 멘붕올 일이 없습니다!

내 코드에 자신감이 뿜뿜 생긴다

예전에는 코드 한 줄 수정한 게 다른 기능에 영향을 미칠까봐 항상 두려웠습니다. 하지만 테스트 코드를 만들면 내 코드가 잘 돌아간다는 확인을 받을 수 있습니다.

 

이렇게 중요한 테스트 코드를 미리 만들고 구현하는 과정을 TDD(Test Driven Development) 라고 부릅니다.

 

어떻게 짤 것인가

하지만 막상 테스트 코드를 짜려면 막막하기만 합니다. 여기, 테스트 코드의 기본적인 규칙을 소개합니다.

범위 잘 쪼개기

테스트 범위는 자기가 정하기 나름입니다. 중요한 건, 하나의 관심사에 집중하는 겁니다. 내가 만약 결과값이 1인지를 확인해야 한다면 그 내용만 분리해서 테스트 코드를 작성하는 것이죠.

포괄적인 테스트

보통 우리는 내 코드가 잘 돌아갈 것이라는 믿음으로 프로그래밍을 합니다. 다른 사람이 내가 짠 프로그램을 테스트 하다 에러가 나면 이런 말 한 번씩 해보셨을 거예요.

 

제 꺼에선 잘 돌아가는데요?

 

개발자는 항상 다양한 경우의 수를 생각해서 대처해야 합니다. 받아야 하는 값이 null이 될 수도 있고, 여러 개 받으면 다른 결과를 낼 수도 있습니다. 방심하지 말고 포괄적으로 테스트를 해야 합니다.

테스트가 아니라 기능에 초점 두기

테스트 코드를 짤 때는 이걸 어떻게 테스트로 짜는지 생각하는 게 아니라, 이 기능을 어떻게 표현할지 생각해야 합니다. 어떤 조건에서 어떤 행동을 할 때 이런 결과가 나온다는 걸 명확하게 표현하도록 연습해보세요.

테스트 코드는 타이밍

개발을 하다보면 완성하기에 바빠서 테스트 코드를 미루게 되죠. 시간이 지나면 귀찮아서 결국 테스트 코드를 포기하게 되구요. 그래서 테스트를 먼저 만들고 실제 코드를 만들도록 습관을 들여놓는 게 좋다고 합니다.

 

몰랐던 테스트 코드의 핵꿀팁

테스트 코드는 기능을 테스트 하는 것 외에도 새로운 기술을 배우는 도구가 될 수 있습니다.

학습 테스트

토비의 스프링 저자 토비님은 다른 사람이 만든 코드나 프레임워크를 이해해야 할 때 테스트 코드를 먼저 만들어본다고 합니다.

 

그럼 나중에 실제 개발에 들어갈 때 참고할 수 있는 건 물론이고, 이 코드에서 파일을 어떻게 불러오고, 초기화 하고, 출력하는지 등등의 과정을 직접 만들어보며 알 수 있어 책보다 머리에 잘 들어오고 즐겁다고 하네요.

 

저도 학습 테스트라는 개념이 정말 새롭고 감명 깊어서, 스프링 예제로 유명한 petclinic을 다운 받아 테스트 코드를 만들어보고 있답니다!

 

 

실제 러닝 테스트로 작업하고 있는 petclinic 코드

 

스프링을 만든 갓개발자들의 테스트 코드를 직접 보고 따라할 수 있는 게 얼마나 행운인가요! 테스트 코드에 익숙하지 않은 분이라면 특히 강추합니다.

 

사람이 TDD가 미래다!

토비의 스프링에서는 테스트 코드를 강조하면서 이런 말을 합니다.

눈물 젖은 커피와 함께 며칠간 밤샘을 하며 오류를 잡으려고 애쓰다가 전혀 생각지도 못한 곳해서 간신히 찾아낸 작은 버그 하나의 추억은 개발자가 진작에 충분한 테스트를 했었다면 쉽게 찾아냈을 것을 미루고 미루다 결국 커다란 삽질로 만들어버린 어리석은 기억이다.

네...너무나 제 얘기고요?🤣제대로 뼈 맞고 순살됐네요.

 

어쩌면 어떤 분은 절대 이 코드를 바꿀 일이 없다고 단언하며 테스트 코드의 필요성을 의심하실 겁니다. 하지만 저는 감히 이렇게 말씀드리고 싶어요.

변하지 않는 건 (월급 빼고) 없다

당장에 수정할 계획이 없더라도 언젠가 필요한 상황이 생기면 그때는 돌이킬 수 없습니다. 미리미리 테스트 코드를 준비해놓으면 미래의 나를 살릴 수 있어요!

 

스터디 회고

이번 회차는 제가 직접 발표 준비를 했기 때문에 더 기억에 남고 흥미로웠던 것 같아요. 게다가 스터디원들이 주옥같은 말을 많이 해주었습니다. 아무래도 저는 현업에서 테스트 코드를 짜본적이 없기 때문에 멤버들의 경험 공유가 큰 도움이 되었어요.

 

어떻게 하면 테스트 코드를 더 잘 짤 수 있을지, 좋은 라이브러리는 무엇이 있는지 꿀팁 공유는 물론이거니와, 테스트 코드를 짜놨다가 구현 코드를 고치면 테스트 코드도 같이 수정해야 해서 회의감을 느낀다는 고민을 털어놓는 멤버도 있었습니다.

 

이런 유익한 토론 내용을 한 번 듣고 흘려보내는 게 아쉬워 깃헙에 따로 기록했습니다. 심심하면 놀러오세요!

 

https://github.com/DE-labtory/sc/issues/4