Día de Ruru

서버는 제대로 배포가 되었는데 유저테스트를 진행하기 전에 서버 모니터링이나 서버 부하테스트를 해보고 싶어서 이것저것 알아보다가 Artillery를 알게되었다. Artillery는 간편하게 서버의 부하테스트를 해볼 수 있는 라이브러리라고 한다. ☆알게된 것★ Artillery 로 서버 부하 테스트하기 아래 처럼 config에 어떤 환경에서 테스트를 할 지 적어준다. target에는 테스트할 url을 적어주면 된다. 지금 배포되어 있는 서버주소로 테스트를 하면 갑자기 프로덕션 서버에 문제가 생길 수도 있기 때문에 로컬서버와 테스트용 DB로 테스트를 임의로 해주었다. 원래는 스태이징 서버나 스태이징 DB를 따로 구성한 후 테스트를 한다고 한다. scenarios에는 테스트 시나리오를 작성해준다. 아래의 시나리..

1. 중간발표 끝!! - 중간 발표가 끝났다~~ 뭔가 아쉬웠던 점도 있었고 끝내 잡지못했던 에러도 있어서 속상한 부분도 있었는데 어찌어찌 잘 끝났다!! 심지어 트랜잭션 사용한 걸로 칭찬도 받았다 그런데 프론트에 대한 질문이 거의 없어서 뭔가 찝찝했다... 다음주 멘토링때 좀 더 자세히 멘토링 해주신다는데 뭔가.... 뭔가 너무 아쉽다 ㅜㅠㅜㅜㅜ 3주동안 열심히 준비했는데 프론트 질문이 없어서 내가 다 아쉽다 나도 이렇게 아쉬운데 프론트 선생님들은 얼마나 아쉬울까 기분 안좋을 것 같다 2. 역시 나 또 생긴 소통의 오류 급하게 이것저것 개발에 몰두하다보니 소통에 오류를 많이 겪었다. 나는 전달했다고 생각했는데 전달이 안되어서 생겼던 오류라던가(철환님한테는 내가 api 변경하고 서버 재배포하면 알려준다고 했..

질문 jest를 사용한 테스트코드에서 repository를 mock 할 때 naverUsersService.naverUsersRepository = Object.assign( {}, mockNaverUsersRepository ); 이렇게 사용하는 이유가 뭔가요? 대답 위 코드는 Jest를 사용하여 테스트 코드를 작성할 때, 테스트 대상 객체(naverUsersService)의 의존성 객체(naverUsersRepository)를 Mock 객체로 대체하기 위한 방법 중 하나입니다. Mock 객체는 실제 객체와 동일한 API를 제공하지만, 실제로는 다른 동작을 수행합니다. 예를 들어, 데이터베이스 연결을 모의(mock) 객체로 대체하여 실제 데이터베이스가 아닌 테스트 전용 데이터베이스를 사용하여 테스트를 ..

문제점 mypage.controller의 testcode를 짜려고 하는데 아무리 봐도 정말 흠잡을 곳 없이 잘 짰는데 계속 아래의 testcode에서 막힌다. mypagecontroller.MypageService.checkUserById가 0번 호출된다고 결과가 나오는게 이상하다.. 그럴리가!! expect(mypagecontroller.MypageService.checkUserById).toHaveBeenCalledTimes(1); 해결방안 await mypagecontroller.getUserInfo(mockRequest, mockResponse, mockNext) 1. 테스트코드 세션을 진행했던 멘토님의 슬랙 아이디를 알아내서 디엠으로 여쭤봤더니 지금 코드 자체가 실행이 잘되고 있는지 확인을 해봐..

1. 1차 서버배포 완료!! 서버배포 전 각 API를 테스트한 후 배포를 진행했는데 API가 60개 정도가 되다보니 기능 테스트만 2시간이 걸렸다...매번 이렇게 태스트를 하다간 진짜 진이 다 빠져서 죽을지도..? 팀원들과 테스트코드 공부를 한 후 다음주에는 테스트코드를 짜보기로 했다!! 테스트코드를 잘 짜두면 이번 처럼 배포전에 포스트맨으로 API 하나하나 테스트를 해서 확인한 후 배포하는 짓은 안해도 될꺼같다 중간에 자잘자잘한 수정 사항이 생길 때 마다 그때 그때 손으로 재배포 하는게 너무 힘들고 번거로워서 CI/CD를 구축하게 될 것같다. 팀원들과 이야기 나온바로는 github actions를 사용하게 될 것 같다!! 2. 백앤드 아키텍쳐에 대해서 공부를 좀 해봐야할 것같다. 다같이 레퍼런스를 좀 ..

문제점 1. 권한이 일치하지 않는 게시글이 조회되는 에러 발생 분명 어제까지 잘되던 기능이 리펙토링 이후에 묘하게 이상해졌다.. 내가 언급된 일정만 따로 조회하는 API에서 조회는 잘 되는데 내가 권한이 있는 mentionId가 아니라 같은 일정이긴 하지만 권한이 다른 팀원에게 있는 mentionId 를 가져오는 경우가 생겼다.. 뭔가 찾아오는 부분에서 findOne을 할 때 내가 원하는 데이터가 아니라 가장 앞에 있는 데이터를 가져오는 것 같다. 해결방안 1 아래의 코드가 내가 처음 작성한 코드이다. 테이블 조회를 애초에 schedules 테이블을 기준으로 했기 때문에 관계성이 연결되어있지 않은 mention 테이블은 따로 조회한 후 assign() 메서드를 활용해서 하나의 객체로 합쳐버렸다... co..