Redis Insight

테스트코드 없이 테스트 작업을 진행 하면서(.. 테스트코드 공부해야되는데..)

redis cache에 대한 직관적인 확인이 필요해졌고, 캐시를 한 눈에 모아볼 수 있는 도구인 redis insight gui에 대해 알게되었다.

 

redis를 실행하고 insight를 실행하면 정상적으로 캐시들이 보이고, 편하게 테스트 할 수 있다.

원래 캐시가 꽤 많았는데 테스트 다시 하려고 다 지운 상태다 ㅎ

 

이제 요 며칠 간 열심히 만든 api들을 테스트 해보자!

목표는 캐싱 작업이 정상적으로 진행되는걸 내 눈으로 보는것이다.

그리고 swagger가 있음에도 왜 사람들은 postman을 사용하는가? 에 대해 튜터님께 여쭤봤는데, postman이 테스트 기록도 남고 코드에 주는 영향도 적고 확실히 사용이 편하다고 하셨다.

postman은 json 입력을 사용자가 해야된다는 단점이 있지만 이전 기록을 불러와서 테스트 하면 된다고 한다.

오늘까지만 swagger를 사용하고 이후부터는 아스키독스나 postman을 사용해봐야겠다.

아스키독스 코드도 보여주셨는데, 아스키독스는 모든 api에 대해 테스트 코드가 필요하다고 좀 불편한 면이 있다고 하신다.

 

우선 로그인 사용자의 글쓰기부터 체크해보자. 내 서비스에서 로그인 된 사용자는 1분에 10번, 비로그인 사용자는 1분에 2번 글을 쓸 수 있다.(updatedAt은 좀따 고칠거다 지금은 귀찮다)

작성 후 24초가 지나서 38s라고 뜨는데 정상적으로 캐시가 등록되었다. 그리고 이로부터 38초가 지나자 캐시가 사라졌다!

 

이번에는 1분에 10번 글을 작성해보자.

짠 이렇게 11회라 체크되면서

오류메세지도 정상적으로 띄운다.

 

이번에는 좋아요에 대해 체크해보자. 로그인 사용자는 같은 글에 대해 하루 2회, 비로그인 사용자는 하루 1회 가능하다.

좋아요를 두번 누르자 오류가 났다. 3번째에는 정상적으로 에러메세지를 출력한다.

일단 좋아요에 대한 캐시는 정상적으로 들어온다.

추가로 좋아요를 누를 때 cache가 업데이트 되도록 했는데 이것도 설정한 TTL에 맞게 잘 들어왔다.

이제 캐시 메모리를 바탕으로 6번 포스트를 조회해보자.

6번 데이터에 접근하려 하자 오류가 났다.

캐시값을 boardresponsedto로 변환하는 과정에 생긴 오류같다.

cacheManager쪽 직렬화/역직렬화 설정을 좀 만지면 될 듯 하다. 일단 오늘은 오류들로 너무 피곤하니 여기까지만.....흑흑

사실 redis insight가 실행이 계속 안돼서 좀 고생을 했다.. 내눈으로 캐시를 확인한 것 만으로 만족스럽다.

 

뭔가 아쉬워서 익명유저 테스트(ip로 검증을 한다.) 도 해봤는데 잘 돼서 기분이 좋다.

근데 ipv4로 하는것같아서 가능하다면 ipv6으로 바꾸고싶다.

마무리로 좋아요가 10 넘으면 달리는 핫데이터 title 헤헤