테스트 코드
처음으로 테스트 코드라는 것을 작성해 보았다. 단위 테스트, 통합 테스트에 대해 공부하고 그것을 적용해 테스트 코드를 작성했다. 테스트 코드는 말 그대로 테스트이기 때문에 간단할 것이라고 생각했지만 생각보다 고려할 것이 많았다. 물론 그냥 내 맘대로 짜면 짤 수도 있었겠지만, 무엇이 좋은 테스트인가? 어떤 것을 테스트해야 하는가? 모킹은 어느 정도 수준까지 해야 하는가? 테스트 해야 할 흐름은 어떤 것들이 있는가? 즉, 최적의 테스트 라는 게 무엇인지를 깊이 탐구하는 것과, 그것을 알기 위해 테스트라는 것 자체를 깊게 이해해야 했기에 많은 시간이 걸렸던 것 같다.
테스트는 보는 이로 하여금 테스트의 의도가 명확히 전해져야 하고, 그것을 위해 조금의 불편함도 감수할 수 있어야 한다. 쓸데없이 복잡한 것이 좋은 테스트가 아니며, 필요한 부분만 간결하고 확실하게 테스트 하는 것이 좋다. 모킹은 가능하다면 전부 다, 그리고 명확하게 하는 것이 나쁜 것은 아니지만, 예를 들어 예외 처리 흐름을 검증하는 테스트인데 예외 처리 이후 메서드까지 전부 모킹 한다거나/사용되지 않거나 중요하지 않은 변수들에 모든 필드 값을 전부 할당한다거나 식의 테스트는, 보는 이로 하여금 이 테스트가 무엇을 검증하려는 것인지, 무엇이 중요한 것인지 헷갈리게 할 수 있다. 나는 테스트라는 것을 이 정도로 이해한 것 같다.
썬카는 차량 관련 엔티티만 10개이기에 테스트용 데이터를 만드는 데에도 굉장한 시간이 소요되었다. 앞으로 이런 저런 기능들이 더 붙을 텐데 그럴 때마다 일일이 테스트 데이터를 만들고 있으면 그것만큼 비효율적인 일이 또 있을까 싶었다. 그래서 팩토리 클래스를 만들었다. static 메서드 하나만 호출하면 테스트 데이터를 사용할 수 있도록 말이다.
하지만 팩토리 클래스는 단위 테스트에서는 아무런 가공 없이 사용할 수 있었지만, 통합 테스트에서는 달랐다. 통합 테스트는 실제 DB와 상호작용해야 했기 때문에 영속화된 엔티티가 필요했고, 실제로 DB에 저장해야 했다. 그러다 보니 엔티티 간 외래키 관계 때문에 엔티티 생성 순서가 매우 중요해졌다. 기존 팩토리 클래스는 완전히 개별적으로 객체를 생성했기에, 팩토리 클래스를 업그레이드 하거나 다른 방식을 강구해야 했다. 그러나 팩토리 클래스를 구체화해 영속화를 추가하고, 엔티티 생성 순서까지 전부 고려해 메서드를 추가하고 하면 팩토리 클래스의 책임이 너무 많아지고 뚱뚱해질 것 같았다.
그래서 팩토리 클래스는 그대로 두고 엔티티 영속화를 위한 빌더 클래스를 만들었다. 팩토리와의 책임 분리를 위해 팩토리 메서드를 호출한 후 빌더에서 영속화하는 계층화된 설계를 했고, 외래키 관계를 위해 엔티티 생성 순서를 보장하되 개별 엔티티만 선택적으로 만들 수도 있게 하기 위해 메서드 오버로딩을 통해 구현했다. 또한 통합 빌더도 만들어서 모든 빌더를 한 번에 사용할 수도 있게 했다. 이 작업은 복잡하고 힘들었지만, 완성하고 나니 매우 체계적이고 관리가 쉽고, 사용도 쉬운 형태로 구현되어 꽤 만족하는 부분이다.
방향성 변경
기존에 정했던 스프린트 4는 차량 구매, 판매자 채팅이었다. 차량 구매는 구매 흐름을 구상하고 구현하고, 실제 중고차 거래를 할 수 있도록 확장성도 고려해서 구현해야 했고 판매자 채팅은 웹 소켓을 이용해서 실시간 채팅 기능을 만드려고 했다. 둘 다 처음 해 보는 것이고 이번 스프린트토 쉽지 않을 예정이었다.
그러나 방향을 변경했다. 지금까지는 Create, Read 밖에 없었으니 Update, Delete를 추가하고 배포 및 CI/CD 파이프라인을 구축해서 1차적인 마무리를 짓기로 말이다. 이유는 취업이다. 난 현재 개인 프로젝트를 진행하며, 개발자로 전향한 이후 체감 상 가장 빠르게 성장하고 있다. 내 완벽주의적인 성격 때문에 작은 기능이라도 조금 더 개선된 코드를 작성하기 위해 공부하고 구현하며 많은 성장을 이루고 있다.
그러나 내가 프로젝트를 하는 이유는 무엇인가? 어째서 실력을 올리려고 하는가? 취업 때문이다. 난 지금 작성된 이력서와 포트폴리오가 없어서, 눈길이 가는 채용공고들도 그냥 날리고 있었다. 물론 완벽하게 프로젝트를 완성해서 그때부터 이력서를 넣는 것도 좋지만, 그렇다고 해서 당장 눈 앞의 채용공고들을 그냥 날리는 건 주객전도 된 것이 아닌가 싶었다.
프로젝트를 포기하겠단 것은 아니다. 일단 1차적으로 마무리를 하고 현재까지 진행한 내용을 토대로 이력서/포트폴리오를 작성할 것이다. 그리고 다시 프로젝트를 진행하되, 괜찮은 공고가 보이면 지원할 것이다. 또한 진행된 프로젝트를 기반으로 이력서/포트폴리오도 지속적으로 업그레이드 하려고 한다.
테스트 코드를 제외하면, 스프린트 4는 순식간에 끝났다. 자신이 판매중인 차량 목록 조회, 자신이 판매중인 차량 수정/삭제 이렇게 3가지였다. 백/프론트 합쳐서 하루만에 끝났다. 하루도 아니다. 6시간? 걸린 것 같다. 단순한 기능이었으니 말이다.
이제 남은 건 배포와 Jenkins를 이용한 CI/CD 파이프라인 구축 뿐이다. Jenkins는 처음이라 일단 서치를 좀 하며 가닥을 잡아봤는데 크게 어려울 것 같진 않다. 다만 처음 해 보는 것이라 생각지 못한 변수를 만나 시간이 조금 지체될 수는 있겠다. 정보보안을 했던 것 때문에 리눅스, 네트워크, 인프라 쪽에 익숙해진 것은 큰 장점인 것 같다.
벌써 썬카 프로젝트를 시작한지 거의 2달이 다 되어 간다. 난 프로젝트를 시작할 때, 1달이면 기능 명세서에 있는 모든 기능을 프론트/백 전부 만들 수 있을 거라 생각했다. 근데 택도 없었다. 2달이나 됐는데 아직도 구현 못한 게 많이 남아 있다. 심지어 기능 명세서에 추가하지 않은 다른 기능들도 내 머릿속에 많다. 물론 지금까지 작성한 코드의 퀄리티는 나름대로 마음에 드는 편이지만, 내 머릿속에 있는 모든 기능을 전부 완벽하게 만들고 이력서를 넣는다고 생각한다면 그건 아마 6개월은 걸릴 것이다. 그건 너무 길다.
나의 취준은 너무 길어지고 있다. 물론 누군가 나에게 이렇게 긴 취준기간동안 무엇을 했냐고 물어본다면, 나는 어떤 것들로 채워왔는지 한 숨도 쉬지 않고 자신있게 말할 수 있다. 그렇게 열심히 보낸 기간들이다. 전혀 아깝지 않은 시간들이었다. 그러나 절대적인 시간이 너무 길다. 나이도 벌써 29살이다. 나는 한 시도 쉬지 않고 계속해서 달려왔는데, 남들보다 열심히 살면 살았지 대충 산 것 같지 않은데 아직도 백수이고 곧 30을 바라보고 있다.
이력서를 버리고 개인 프로젝트를 완벽하게 완성할 정도의 시간이 나에겐 없다. 한 번에 하나만, 완벽하게 끝내고 다음 일로 넘어가는 것이 내 스타일이고 이번에도 그렇게 하려고 했지만, 그런 고집을 부리기엔 난 너무 많은 시간을 사용했다.
=============
아래는 단위 테스트와 통합 테스트에 대해 공부하고 설명한 글이다.
https://yskisking.tistory.com/319
스프링 부트 테스트 전략 - 단위 테스트와 통합 테스트
테스트 코드는 매우 중요하며, 개발자에게 있어 필수적인 핵심 역량이다. 서비스 규모가 작을 때야 코드를 수정한 후 api 몇 개 직접 호출하면 금방 테스트할 수 있겠지만, 규모가 커져서 api가 수
yskisking.tistory.com
아래는 썬카에서 테스트 코드를 구현한 것을 설명한 글이다.
https://yskisking.tistory.com/320
[썬카/백엔드] 서비스 계층 및 커스텀 리파지터리 테스트 코드 작성, 팩토리/빌더 클래스 설계와
썬카의 기능이 조금씩 많아지니, 코드를 수정할 때마다 매번 Postman으로 api를 호출해보는 나를 발견할 수 있었다. 이 작업이 번거롭다고 느껴지는 순간, 테스트 코드를 도입할 때가 왔다고 느꼈
yskisking.tistory.com
=============
썬카 노션
https://lava-move-d1e.notion.site/SunCar-1a754e6b788180f598cdea3bfaff3139?pvs=4
깃허브