학습 키워드Unit Test / Integration Test / E2E Test테스트 Pyramid테스트 커버리지 vs 유의미한 테스트유닛테스트라는건 뭘까?서비스단에서? 컨트롤단에서? 음 아무래도 상관없으려나유닛테스트는 단위테스트라고 하며그림을 보면 알수 있듯이 단위 테스트는 테스트 피라미드 바닥에 존재하며 굉장히 많은 수 가 있다는 것을 알 수 있습니다.이는 간단하게 작성이 되어진다는 뜻이 되어집니다.이전 포스트에서도 말했었지만 테스트코드는 굉장히 중요합니다. 그렇다는 이야기는 e2e를 하든 통합을 하든 유닛을 하든작성을 하는것이 좋습니다. 여기서 중요한 사실은 유닛테스트가 양이 제일 많다는 것입니다. 그렇다는건 유닛테스트를 중점으로 테스트코드를 짜야 된다는 뜻이 됩니다.그리고 그림에서 보면 알 수 ..
10주간을 되돌아 보며10주동안 이커머스에서 발생할 수 있는 여러가지를 학습을 하였다. 1주차로 워밍업을 하고 2~10주차에서 본격적으로 설계를 진행하였다.사실 어떤것을 학습을 하였는지 구체적으로 기억은 잘 나지 않는다. 일단 기억이 나는데로 얘기를 해보자면1주차1주차때 테스트 코드를 작성하였다. 테스트 코드의 중요성은 잘 알고 있었지만 뭐랄까 막연한 두려움이 있었다. 어떻게 작성하면 될까...@DisplayName("두개에서 한개를 제거하는 경우, 주문 상품의 갯수는 한 개를 리턴합니다.")@Testvoid returnOrderItemSizeIs1_whenRemove1Product() { //given OrderItemModel orderItem1 = OrderItemModel.builder() ..
랭킹이라가는건 뭘까 단순한 줄 세우기인가어떤 기술을 사용하면 효율적일까?사실 랭킹은 생각보다 쉽다.정확히 말하면 쉽게 생각할 수록 쉽게 만들 수 있는거라 생각한다.랭킹은 RDB로 하는것이 좋을까? 아니면 nosql로 하는것이 좋을까?정답은 없다고 생각한다.어떤 기술을 사용해야 한다는것은 없다고 생각한다.nosql중에는 레디스를 활용해서 데이터를 저장한다.결국 RDB랑 레디스와 비교를 하는것이 중요하다고 생각이 든다.어떤것이 더 랭킹 시스템에 어울릴수 있는지 생각할 수 있을거 같다.나는 랭킹 시스템을 레디스로 만들었는데 그 이유는 낮은 오버헤드와 읽기 성능이 좋다는 것을 높게 평가하였다.레디스는 다양한 자료구조를 지원하는데 그 중에서도 Zset을 이용하게 되었다. Zset은 레디스가 가지고 있는 낮은 오버..
배경카프카에서 수신한 정보를 토대로 계산하여 랭킹을 산출하고 있었다. 지금 보여주고 있는것이 사용자가 원하는 랭킹일까?잘 모르겠다. 실제로 운영이 되지 않는점도 크다고 생각한다. 만약 실제로 운영 된다면, 사용자들이 자주 들어오는 시간을 측정해서 가중치를 반영할 수도 있다 생각한다. 실제로 운영되는 환경이 아니기 때문에 부하테스트를 돌려서 확인하는것이 최선이지 않나 싶다.랭킹 서비스를 만들기 위해서는 데이터를 저장을 해야 한다. 그래야 그걸 통해 정보를 보여줄 수 있기 때문이다. 그래서 최대한 예상을 해서 작성해보려구 한다.수신 장치현재 카프카를 통해 데이터를 수신하고 있다.각 토픽에 맞게 메시지를 전송하고 있다.@Component@RequiredArgsConstructorpublic class Prod..
사실 카프카에 대해 잘 모르겠다. 아직..카프카가 고가용성이라고는 하지만 이게 개발자인 나에게 엄청나게 와닿지는 않았다.나야 프로듀서에서 컨슈머로 데이터만 잘 전달만 하는게 목적이기 때문이라 생각이든다.그렇다고 해서 저 부분이 중요하지 않는다는건 아니다.내가 말하고 싶은건 개발자인나에게 저것보다는 어떻게 사용할 수 있는냐가 더 중요하지 않나 생각이든다.그래서 그 부분에 초점을 맞춰서 공부를 했던거 같다.프로듀서의 개념토픽의 개념파티션키의 개념컨슈머의 개념배치 리스너 오프셋 개념..등등 여러가지 개념들을 그 초점에 맞추면서 공부를 하였다.저 개념들을 100% 전부 이해한건 아니지만 이제 시작이라 생각이 든다. 하나하나 전부 이해한것은 아니지만적어도 커다란 맥락에서 저러한 개념들을 왜 사용하는지 확실하게 이..
