Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 대시보드

초급자를 위해 준비한
[소프트웨어 테스트, Spring] 강의입니다.

Spring에 테스트를 넣는 방법을 알려드립니다! 더 나아가 자연스러운 테스트를 할 수 있게 스프링 설계를 변경하는 방법을 배웁니다.

프로젝트 설계를 발전시키는 
테스트의 본질을 짚어드릴게요! 

Spring에 테스트를 넣는 방법으로 시작해, 아키텍처 강의로 끝납니다!

테스트에 대한 올바른 의견을 전달해 드리려면, 결국 아키텍처로 끝나야 한다라는 생각을 했기 때문입니다. 

테스트에 대한 기본적인 개념을 배우고, Spring(스프링)에 테스트를 어떻게 넣어야 하는지 배웁니다. 더 나아가 자연스러운 테스트를 할 수 있게 스프링 설계를 변경하는 방법을 배웁니다.

그래서, 이런 내용을 학습합니다.

그런데 혹시, 이런 생각이 들진 않나요?
테스트에 대한 고민과 오해들 

“테스트를 정말 간절히 넣어보고 싶습니다. 그런데...”

다른 회사 다니는 친구는 시대의 요구에 발맞춰서 테스트를 꾸준히 넣어가며 차근차근 성장하고 있습니다. 그런데 우리 회사는 테스트를 넣지 않아요. 뒤처지고 싶지 않습니다. 공부할 의지도 있습니다. 그런데 도저히 이 레거시 시스템에 테스트 코드를 어떻게 넣어야 할지 감이 안 옵니다.

“H2를 이용한 테스트에 신물이 납니다.”

H2를 이용한 테스트는 너무 느리고 DB에 지나치게 종속적입니다. 모든 테스트가 H2를 이용하고 있습니다. 테스트를 돌리기는 부담스럽고, 테스트들이 h2를 공유하다 보니 데이터가 뒤엉켜서 어떨 때는 테스트가 성공하고, 또 어떨 때는 실패합니다.

“테스트의 필요성을 못 느끼겠습니다.”

우리 팀은 사람이 그렇게 많지도 않고, 배포하면서도 그다지 불안함을 느낀 적이 없습니다. 요구사항은 시시각각 변합니다. 근데 TDD를 어떻게 하나요? 테스트는 개발 속도만 늦출 뿐이라고 생각합니다.

테스트, 저도 같은 고민을 했습니다.

시중에 나와 있는 테스트 관련 책이나 세미나를 찾아보면 대부분 그냥 테스트의 장점, 테스트 코드 짜는 법, JUnit, Mockito 정도만 얘기하고 끝납니다. 예제는 딱 입문자의 입맛에 맞을 만큼 간단한 예제 뿐이고요. 그래서 마지막에 가서 책을 덮을 때면 이런 생각이 듭니다.

• "대체 이걸 현업에서 어떻게 쓰라는 거죠?"
• "Spring에는 테스트를 어떻게 넣으라는 건가요?"
• "이건 프레임워크가 없는 상황에서 넣는 테스트니까 쉽게 넣을 수 있는 거 아닌가요?"

혼란스러웠습니다. H2를 이용한 JPA 테스트... 뭐 좋습니다. 그런데 ElasticSearch나 Cassandra처럼 테스트용 DB가 없으면 어떻게 테스트하라는 걸까요? 게다가 H2를 이용한 테스트는 정말 치명적일 정도로 느렸습니다. 하루에도 여러 번 돌리기 부담스러웠고요. 테스트는 자주 깨지고 DB 테이블이라도 변경되는 날에는 관련된 테스트도 싹 다 수정해야 해서 시간 낭비 같다는 생각이 들기 일쑤였습니다.

TDD를 공부하려면, TDD부터 공부하면 안 됩니다.

그러던 중 저의 고민들은 아키텍처와 DDD를 공부하기 시작하면서 모두 해결됩니다. 알고 있습니다. TDD는 항상 핫하죠. 그런데 TDD는 정말 매력적이면서도 어려운 방법론입니다. TDD를 해본 적 없는 조직에서 TDD가 유행이니 이제부터 TDD로 개발하려고 하면 그게 될까요? TDD는 생각보다 시작하기 전에 알아야 할 선수 지식과 공감대를 정말로 많이 필요로 합니다.

그래서 TDD를 공부하려면 TDD부터 공부하면 안 됩니다. 테스트를 먼저 공부해야 합니다. 미적분을 하려면 방정식부터 다룰 줄 알아야 하는 것처럼 말입니다.

테스트에 대한 고민을 
명쾌하게 해결해드릴게요.

Spring 개발자에게 꼭 필요한 
테스트 넣는 법을 배워야 합니다.

• ✅ 실무와 동떨어진 테스트 넣는 방법을 알려드리지 않습니다.
• ✅ Spring 개발자에게 필요한 테스트 넣는 법을 알려드립니다.
• ✅ 그러면서 동시에 왜 이렇게 해야 하는지를 알려드립니다.

이 원리를 기반으로 한 지식은 다른 프레임워크에서도 통용되는 지식들입니다. Nest.js를 사용하시던, Swing UI를 사용하시던, Gin을 사용하시던... 어디에서든 적용될 수 있는 지식이라 생각합니다.

종장에 가서는 설계에 대한 강의로 이어집니다. 테스트의 가치를 최대한으로 설명해 드리기 위해선 설계에 대한 내용이 빠져선 안 된다 생각했기 때문입니다. 

적어도 제가 찾아보기론 국내의 스프링에 테스트를 넣는 법을 알려주는 책이나 강의는 못 본 것 같습니다. 모두 @Mock, @Spy 이런 어노테이션을 이용하여 mocking하고 의존성 주입 받아 테스트를 작성합니다. 하지만 만약 이런 Mock 라이브러리가 존재하지 않는 환경이라면 어떻게 테스트 하실 건가요? 본질적으로 이러한 어노테이션이 없어도 테스트하는 방법을 알아야 합니다! 그리고 테스트해야 할 대상이 무엇인지도 구분할 수 있어야 합니다. 

테스트를 테스트답게 추가하는 
방법을 알려드립니다!

오리엔테이션

테스트를 추가하고 싶은 조직에서 TDD를 도입할 때 실패하는 이유를 살펴봅니다. 일반적으로 내가 하는 TDD는 왜 실패하는지 살펴봅니다. 테스트에 대한 제대로 된 이해 없이 테스트를 무작정 넣기 시작했을 때 발생하는 문제점들을 같이 살펴봅니다.

테스트에 대한 이론

기본적인 테스트 지식을 공부합니다. 테스트의 필요성에 대해 공감하고 테스트와 설계의 상관관계를 파악합니다. 테스트를 만들면서 개발자는 어떤 고민을 해야하는지 이해합니다. 최종적으로 자연스러운 테스트를 위해 Testability를 높이는 작업에 대해 같이 살펴봅니다.

1부 - 토이프로젝트 기반 테스트 적용

앞으로 사용할 토이 프로젝트를 같이 살펴봅니다. 그리고 토이 프로젝트에 어거지로 테스트를 넣어보며 최대한 테스트를 넣어 커버리지 100%를 달성해봅니다. 이 과정에서 h2, MockMvc, PowerMock같은 외부 라이브러리들을 사용합니다.

최종적으로 만들어진 테스트들을 같이 살펴보며 회귀 버그만을 커버하기 위한 테스트에는 어떤 문제가 있는지 살펴봅니다.

방향성 탐색

우리의 토이 프로젝트에 테스트를 넣은 게 그다지 좋은 방향이 아닌 이유를 같이 살펴봅니다. 더불어 전통적인 레이어드 아키텍처의 문제점에 대해 같이 살펴봅니다. 그리고 어떤 식으로 개선할 것인지, 강연자의 의견을 들어봅니다.

1부 실기에서 무작정 테스트를 넣기 위해 고군분투했다면, 2부에서는 Mockito 같은 외부 라이브러리 없이도 자연스럽게 Mock하는 방법을 익힙니다. 2부 실기를 위해 미리 어떻게 코드를 바꿀지 같이 살펴봅니다.

2부 - 토이프로젝트 구조 설계 개선

앞선 방향성 탐색을 통해 얻은 인사이트를 우리의 토이 프로젝트에 도입합니다. 이 과정에서 구조적인 변화를 줘가며 설계를 개선합니다. 그리고 이 과정에서 아래와 같은 기법들이 사용됩니다.

• 패키지 구조 개선
• 도메인과 영속성 객체를 구분하기
• 서비스 로직을 도메인으로 가져오기
• 외부 연동을 의존성 역전하기
• 테스트를 소형 테스트로 만들기

진화하는 아키텍처

테스트와 설계의 상관관계를 통해 아키텍처를 진화시키는 방법에 대해 같이 살펴봅니다. 레이어드 아키텍처가 어떻게 헥사고날 아키텍처로 변하는지 살펴봅니다. 관심사를 분리하면서 개발자가 도메인에 집중하는 방법을 배웁니다.

개발자로 성장하는 데  
도움을 드리고 싶습니다!

안녕하세요, 김우근입니다! 👋

현재 카카오에서 일하고 있고, 만드는 것을 좋아해서 퇴근 후에도 항상 무언가를 개발하고 있습니다. "거인의 어깨 위에 선 난쟁이"라는 말이 있습니다. 저 역시 한낱 작은 난쟁이일 뿐이지만, 올라탄 거인의 성장에 도움이 될 수 있도록 지식의 대물림을 위해 노력하고 있습니다. 다수의 주니어 개발자 분들을 멘토링한 경험이 있어서 여러분의 성장을 도와줄 수 있을 거예요.

• ✅ Github / Blog
• ✅ 현 카카오 백엔드 엔지니어
• ✅ 공개 SW 개발자대회 2020 일반부문 금상: 정보통신산업진흥원장상 수상
• ✅ 인프런 강의 Java/Spring 주니어 개발자를 위한 오답노트

Q&A 💬

이런 분들께 추천드려요!