[인프런 강의] Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트를 듣고

 

https://www.inflearn.com/course/%EC%9E%90%EB%B0%94-%EC%8A%A4%ED%94%84%EB%A7%81-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%98%A4%EB%8B%B5%EB%85%B8%ED%8A%B8

Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트 | 김우근 - 인프런

 

 

아키텍처에 정답은 없다. 문제와 해결과정만 있다.

 

이 강의를 요약하면 다음과 같다.

 

레이어드 아키텍처에서 테스트를 구현하고, 레이어드 아키텍처의 문제점을 지적하면서 헥사고날 아키텍처로 리팩토링을 진행하면서 테스트를 재구현한다.

 

이 강의를 듣고 난 역시 우물 안 개구리였다는 생각이 번쩍 들었다.

 

현재 프로젝트의 문제를 정확히 지적해주면서, 설계 방식 & 리팩토링까지 가이드해주는 강의라니 !

 

강의가 더 공감갔던건 아무래도 강의자 분의 생각이 내 생각과 비슷해서지 않을까 싶다.

 

나는 TDD는 비관적이지만 필수 테스트는 존재하고, 꼭 필요하다고 생각한다.

 

이 부분을 정확히 짚어주고 넘어가는 강의라 더욱 인상적이었다.

 

그리고 현재 프로젝트의 상황이 서비스 규모가 커짐에 따라서 테스트에 대한 필요성이 점점 커지고 있는 상황이었다.

 

현재 딱 저위치인 것 같다.

 

코드가 늘어감에 따라, 수정에 따른 사이드이펙트가 계속해서 발생하고 있었다.

 

이걸 고쳐도되나? 하는 부분들이 점점 부담으로 다가오고 있었다.

 

강의에서 자주 이야기가 나오지만 테스트가 잘못됐다는 신호를 보는게 아니라

 

그냥 프로젝트가 테스트를 넣어주세요라고 신호를 보내는 상황이었다.

 

그런데 테스트 쪽의 초심자인 내가 생각하는 몇가지 문제가 있었다.

 

1. 내가 알고 있는 테스트는 DB를 연동하는 부분이 많아서 실행 시간이 너무 오래걸림

2. 그래서 mock을 사용하게 될 거같은데, 그럼 어디까지 mocking이 필요한가?

3. 테스트도 WebMvcTest, SpringTest, MockTest 이런 것들이 있는데 어떤걸 써야하나?

 

결론은 다 필요 없었다.

 

중요한건 좋은 테스트를 하기 위한 아키텍처였다.

 

그리고, 놀라웠던건 좋은 테스트를 하기 위한 아키텍처가 내가 고민해왔던 아키텍처 문제에 대한 해결책이었던 것이다.

 

1. 현재 프로젝트는 레이어드 아키텍처를 쓰고 있고 있으며,

2. 모델에 대한 구분이 제대로 되어 있지 않다보니 엔티티와 객체들이 무분별하게 생성되고 있었다.

3. 그리고 제대로된 추상화가 되어 있지 않아서 작업의 경계가 모호했다.

 

나와 비슷한 고민을 하고 있는 사람이라면, 이 강의를 통해 고민들은 꽤 해결할 수 있을 것 같다.

 

하나의 프로젝트를 수정하가며 하는 단순한 강의였지만, 나에게는 너무 크게 다가왔다.

 

물론 어떻게, 어디까지 테스트를 구현하고 구조를 수정할지에 대한 고민과 논의는 필요한 상태이다.

 

테스트 초심자기 때문에 여차하면 쓸모없는 구역에 대한 테스트가 늘어갈 거라 생각한다.

 

하지만, 이 강의를 통해 테스트가 반드시 필요하다는 확신을 얻게 되었다.

 

현재 이 내용을 바로 적용해 볼 수 있는 작은 프로젝트가 있다는 점도 다행인 상황이다.

(문제는 메인 프로젝트와 다른 코틀린이라, kotest를 이용해서 작성하면 메인 프로젝트와는 조금 다르지않을까 생각한다..)

 

그리고, 마지막으로 헥사고날 아키텍처에 대한 짧은 소개를 해준 것도 좋았다.

 

아키텍처와 설계에 대한 고민 때문에 클린코드, 오브젝트, 클린 아키텍처, 만들면서 배우는 클린 아키텍처 등의 책을 읽고 있던 차에 또 좋은 방향성을 얻은 것 같다.

 

마치며

나는 스타트업 -> 중소 SI -> 중소 서비스 IT회사로 넘어온 개발자다.

 

그러다보니 일정에 쫓기는 MVP 개발에 특화됐다. 

 

문제는 이런 방향으로 개발을 배우다보면 개발은 문제를 해결하는게 가장 중요하다는 생각을 하게 된다는 점이다.

 

틀린말은 아니지만, 시간이 부족하다는 핑계로 디자인 패턴이나 테스트에 소홀해지게 된다.

 

그리고 팀의 규모가 작다보니 협업과 인수인계, 유지보수 등에 투입되는 자원이 중요하다는 것도 놓치기 십상이다.

 

문제가 반복되다보니 코드의 가독성과 구조가 중요하다는 걸 알게 됐지만,

 

어떤 게 올바른 방향인가에 대한 고민은 남아있었다. 

 

그런 점에서 이 강의가 좋은 가이드가 되어 줄 것 같다.

 

백엔드 개발자로서 다음 단계로 넘어가는데 필요한 깨달음을 얻은 강의였다.