test 코드에서 Transactional 필요할 수 있다.

협업을 할때 github organization 그룹을 만들어서 관리하자

branch auth → feat/auth , issue#1

Servicetest → mock (x), save / BeforeEach : 필요 객체 만들어주기

Testcode는 가벼워야 한다. 사용하지 않는 Bean 은 등록 x , Mock 객체

ResponseEntity 헤더안의 내용을 검증하는 것은 ControllerTest 이다.

기능 추가에 따른 외부 API 테스트가 어렵다. (redis, s3)

매일 혼자 해결한 트러블 슈팅, 추가 기능 구현 한 부분 팀원들에게 설명해주는 시간 가지기(코드 리펙토링 하는 시간도 포함)

accestoken 이 만료 되면 클라이언트에있는 refresh token을 api 호출하여 서버에 가져가 db에 있는 refresh token 과 비교하여 accesstoken 재발급, refresh token 값이 같지 않다면 db에서 삭제하고 401(context에서 삭제) 반환후 로그아웃

if (accesstoken == null ) error 처리 후에 로직 진행, validateToken → catch 해주었다면 에러를 JwtUtil.validateToken 에서 로그를 찍고 끝내는 것이 아니라 처리를 해주어야한다. (throw), null값을 반환하면 안된다. (NullPointException)

“Access”, “Refresh” 등 매직넘버 말고 만들어진 static을 쓰는게 좋다

삼항 연산자 부분보다는 if-elseif-else 부분으로 나누는 것이 좋다.

쿼리 최적화에 있어서 서브쿼리는 지양

test 작성 코드에서 dto 부분 생성자 주입이 아니라 mapper 로 주입

테스트에 쓰이는 어노테이션들에 대해 스터디가 필요하다.

any() - 클래스의 인스턴스 주소값과 새로 생성한 객체의 주소값을 같다고 인지 하지 않기 때문에 any()로 같음을 나타내준다.

Todo는 따로 문서 작성해서 관리하자 (주석 X)

데이터 정규화 관점에서는 null 값이 많이 들어가지 않는 편이 좋다. (ex DeletedAt)

파라미터 값이 없는 경우들을 몰아서 테스트 하는 케이스도 있음.