2022 마스터즈 코스(백엔드) 38일차 회고(2022. 3. 2.) - "테스트 코드 작성, 이제는 해야한다."

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

인프런 "스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술" 강의를 어느 정도 들은 이후 본격적으로 이번주에 주어진 1단계 스프링 부트 관련 미션 과제를 수행하기 시작했다. 기존 입문 강의에서 정해진 형태를 참고한 덕에 이번주에 주어진 미션 과제 상의 스프링 부트 웹 애플리케이션 기능 구현 자체는 큰 어려움이 없었다.

 

다만, 스프링 부트 웹 애플리케이션을 구성하는 Controller 부분, Service 부분,  Repository 부분 각각의 부분들을 단위 테스트 소스 코드 파일(특히, Controller)과, 전체 웹 애플리케이션에 대한 통합 테스트하는 소스 코드를 작성하는 것은 개인적으로 내게 어려운 작업이었다.

 

코드스쿼드 마스터즈 코스 과정을 수강하기 전 내가 했었던 테스트라곤 main 메서드에서 System.out.println() 메서드를 활용하여 콘솔 화면을 통해서 결과값을 확인해보거나 웹 애플리케이션의 경우에는 직접 서버를 동작시켜 웹의 동작을 눈으로 확인하는 것들뿐이었다. 이렇게 테스트하는 것을 전문(?) 용어로 스모킹 테스트라고 불린다고 한다.

 

코드스쿼드 마스터즈 코스 과정들을 통해서 많은 것들을 배웠는데 그 중 하나가 JUnit을 활용하여 내가 작성한 로직에 대해 단위 테스트 코드를 작성하는 것이다. 민망하지만 나는 JUnit을 통해 작성한 테스트 코드 자체를 코드스쿼드 마스터즈 코스 과정에 와서 처음 보게 되었다. 그 전까지는 개인적으로 스모킹 테스트만으로 테스트가 충분하다고 생각했었던 탓이다.

 

그동안 많은 수강생분들과 그룹 리뷰를 진행하면서 JUnit을 통해 테스트 코드 파일을 작성하시는 분들을 많이 뵐 수 있었는데 그분들을 통해 처음 JUnit 테스트 코드 파일 작성에 관심을 갖게 되었다. 하지만 관심은 갖았음에도 불구하고 CS10 과정을 할 때는 필요성을 잘 느끼지 못했었기에 매번 다음에 해야지 해야지 미루고 있었다.

 

마침내 웹 코스 과정에 들어서면서 JUint 단위 테스트 코드를 작성할 일이 생겨(이마저도 미션 프로그래밍 요구사항이었음..💦) 처음으로 JUnit 단위 테스트 코드를 작성하게 되었다. 그동안 스모킹 테스트만으로도 만족(?)하고 있었지만 막상 내가 작성한 메서드 내지 기능 단위로 JUnit을 통해 테스트 코드를 작성해보니 이제는 왜 테스트 코드가 중요하다고 하는지 "공감"이 됐다.

 

작년에 스프링 MVC 모듈을 활용해 웹 애플리케이션을 개발하면서 때로는 기능 구현 내지 로직 작성을 하는 일보다 오류가 발생했을 때 어디서 오류가 나는지를 찾는데 더 많은 시간을 쓰곤 했었다. 오류가 나면 어디서 오류가 나는지 System.out.println() 등을 사용하곤 했는데 만약 단위 테스트 코드를 작성하고 있었다면 이러한 오류를 금방 찾아낼 수 있었을 것이다.

 

아울러, 개인적으로 프로토타입 형식으로 구현했던 웹 애플리케이션도 이 정도인데, 웹 애플리케이션의 규모가 커지면 커질수록, 협업하는 사람이 많으면 많을수록 이러한 단위 테스트 코드 작성의 필요성이 부각될 것 같다는 생각이 들었다.

 

 

학습 회고

• 스프링 부트 관련 미션 과제 풀이
  
  • Java 웹 백엔드 클래스 내 소모임원과 zoom 회의실에서 학습

 

인프런 "스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술" 강의가 정말 재미있었기 때문에 마음 같아서는 미션 구현 안하고 강의만 듣고 싶다는 생각도 들었지만 이론과 실전은 다르다는 생각 그리고 그룹 리뷰때 프로그래밍했던 것들에 대해서 공유 내지 논의하고 싶은 생각에 미션 구현을 시작하기로 했다.

 

하지만 강의를 들으면서 어느 정도는 안다고 생각했었지만 웹 애플리케이션을 구성하는 Controller, Service, Repository 각각에 대한 단위 테스트 그리고 통합 테스트 코드를 작성하면서 AutoWired, Bean, 의존성 주입(Dependency Injection) 등에 스프링 기본 지식에 대한 개념 이해도가 아직 부족하다는 것을 느낄 수 있었다. 오히려 강의를 안 듣고 미션 구현을 해봄으로써 내가 어느 부분이 부족한지 알 수 있게 된 계기가 되었던 것 같다. 

 

결론적으로 기능 구현과 단위 테스트 그리고 통합 테스트 소스 코드를 모두 작성하고 오늘 Pull Request를 보내놓긴 했지만 스프링 단위 테스트 코드 작성 역시 처음이기에 아직 많이 부족하다고 생각하며 시간을 두고 기초부터 차근차근 공부해나갈 예정이다. 오늘 학습했었던 주요 내용으로는 다음과 같다.

 

Spring MVC를 이용한 웹 애플리케이션 개발 vs 서블릿을 이용한 웹 애플리케이션 개발

Spring MVC을 이용하여 웹 애플리케이션을 개발하는 것은 서블릿을 이용하여 웹 애플리케이션을 개발하는 것보다는 초기 설정이 복잡하고 프레임워크 구조나 여러가지 애노테이션 등을 이해하는데 어렵지만 추후 유지보수할 때나 협업 시 다른 사람의 코드를 보기가 편하다는 장점이 있는 것 같다.

 

하지만 이번에 Spring boot를 사용해보니 Spring MVC의 복잡한 초기 설정이 상당히 추상화되어 웹 애플리케이션을 구동하는데 큰 어려움이 없었다. 서블릿을 이용한 방법은 반대로 처음 개발할 때는 상대적으로 편하고 빠를 수 있지만, 규모가 커지면 커질수록 유지보수할 때 상당한 어려움이 있을 것 같다.

 

3층 구조 형식의 애플리케이션

3층 구조란 프레젠테이션 계층(사용자 인터페이스 등), 애플리케이션 계층(비즈니스 로직 등), 데이터 계층(데이터 베이스 등)으로 이루어진 구조를 의미하며 이들을 각각 독립된 모듈로 개발하고 유지보수할 수 있는 구조이다. 3층 구조는 기존의 2층 구조의 제한을 극복하기 위해 탄생한 구조로 프레젠테이션 계층과 데이터 계층 사이 중간층인 애플리케이션 계층이 추가된 구조이다.

 

프레젠테이션 계층은 애플리케이션의 최상위에 위치하며, 이는 외부에 다른 계층들과 커뮤니케이션을 한다. 애플리케이션 계층은 비즈니스 로직 계층 또는 트랜잭션 계층이라고도 하며 비즈니스 로직 등을 수행하는 역할을 한다. 데이터 계층은 데이터베이스에 접근하여 CRUD(생성, 읽기, 수정, 삭제) 작업들을 수행하는 역할을 한다.

 

 

좋았던 점

• 부족한 글임에도 오늘 그룹 리뷰에서 소그룹원들께서 글을 잘 봐주고 계신다고 말씀주셔서 힘이 났습니다. 💪

 

 

아쉬웠던 점

• 오늘 오전에 마스터 티타임 일정이 있었다는 것을 깜빡하고 다른 일정을 잡아놓았었기에 마스터 티타임 때 함께 하지 못해 아쉬웠습니다. 💦