본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
패스트캠퍼스의 '9개 도메인 프로젝트로 끝내는 백엔드 웹 개발 (Java/Spring) 초격차 패키지 Online' 강의 수강 25일차!
오늘은 커뮤니티 피드 서비스에 변경된 설계를 적용하는 실습을 진행하였다.
Redis를 도입하여 프로젝트를 리팩토링하기로 했지만, 인수테스트 중심으로 강의를 진행하기 위해 Repository 인터페이스만 만들고 테스트 더블을 사용하기로 하였다. 나중에 Redis 구현체도 직접 만들어봐야겠다.
전에 강의에서 강사님이 질문하셨던 것이 있다.
'실제 사용자 관점에서 요구사항을 만족하기 위함이면, fake/h2 같은 테스트 환경 vs 실제 api 연동이나 mysql 연동 중 어느 방법으로 해야 할까?'
그때 나는 h2와 같은 테스트 환경으로 테스트를 진행한다면 실제 사용하는 mysql 등의 상용 환경과의 차이점 때문에 추후 문제가 발생할 수 있으니, 사용자 관점에서 확인하는 테스트인 만큼 환경을 최대한 맞춰서 진행하는 게 좋을 것 같다고 답변을 했던 기억이 난다.
오늘 강의에서 이 질문에 대한 답변을 해주셨다.
실제로 DB와 Redis도 Docker를 이용하여 이미지를 같이 배포하고 외부 API도 연동을 한다면 프로덕션 레벨에서 정확하게 동작하는 것을 보장받을 수 있다.
하지만, 만약 배포 전에 반드시 테스트를 통과해야만 배포가 진행되는 프로세스라면 문제가 발생할 수 있다.
예를 들어, 외부 API가 갑자기 네트워크 이슈 등으로 인해 동작을 하지 않는다면, 테스트가 실패하거나 배포가 되지 않을 수도 있다.
또한 로컬 환경에서 외부 API 연결와의 연결이 되지 않거나 방화벽에 의해 차단되면, 테스트가 실패하거나 유지보수가 어려워질 수 있다.
그렇기 때문에 DB는 RDBMS와 Docker 등을 이용해 환경을 구성하고, MSA 외부 요청은 Fake 객체로 처리하는 방식과 같이 둘을 적절히 조합하여 인수테스트를 작성하는 것을 추천한다고 하셨다.
구현이 가능한 부분은 실제로 구현하고, 아닌 것들은 테스트 더블을 사용하면 테스트하여 테스트의 일관성을 유지하는 것이 중요하다.
이를 통해 테스트의 안정성과 유지보수성을 높일 수 있다.
만들 수 있는 것은 만들어주고, 아닌 것들은 테스트 더블로 만들어 테스트의 일관성과 유지보수에 집중하는 것이 좋다.
드디어 part1이 종료되었다.
강의를 따라 프로젝트를 진행하면서 객체지향에 대해 다시 알게 되었다.
이전에는 늘 기능 구현을 우선으로 개발을 하다보니 정말 비객체지향적으로 코드를 구현할 수밖에 없었다.
객체를 행동 단위가 아닌 지금 구현하고 있는 기능의 단위로 만들게 되니 당연하게도 코드의 재사용성은 찾아볼 수 없었고, 나도 모르게 동일한 데이터를 가지는 객체들이 여러 개 생성하게 되는 경우도 허다했다.
이번 part1 강의들을 들으며 객체를 행동 단위로 쪼개서 설계하는 것, 저수준 컴포넌트와 고수준 컴포넌트의 흐름이 역행하지 않게끔 개발하는 것, 영속성 컨텍스트에 대한 이해와 JPA, JPQL, QueryDSL 등 상황에 맞는 쿼리를 작성하는 것, 단위 테스트와 인수 테스트 등... 이것 외에도 정말 많은 것들을 경험할 수 있었다.
추상적이고 어렵게만 느껴졌던 객체지향에서 재미라는 것도 느끼게 되었다!
더 많은 코드들을 작성해보며 다양한 상황에서 어떻게 객체지향적인 설계를 할 수 있을지 고민해보는 시간을 많이 가져야겠다.