아장아장거리면서 주책부리는 블로그

로그인을 할 때, 입력값과 출력값을 생각해보자. 입력 아이디 비밀번호 출력 Access Token Refresh Token 발생가능한 예외사항 아이디가 존재하지 않을 때 아이디를 입력하지 않았을 때 비밀번호가 일치하지 않을 때 비밀번호를 입력하지 않았을 때 이 정도의 경우들을 생각할 수 있다. 발생가능한 예외사항부터 처리하고, 성공하는 경우들을 만들어보려고 한다. 예외를 크게 두 방식으로 묶어보자면, @Valid로 인해 생기는 예외(Validation 이용) 자체적으로 Service에서 확인했을 때 발생하는 예외 이렇게 두 가지가 있다. 일단, Validation을 위한 에러에서는, @RestControllerAdvice public class ValidationExceptionAdvice { @Exce..

일단, 블로그 포스팅을 잠깐 쉬면서, 코드를 다시 한번 돌아보았다. 좌충우돌 만드는 게시판 수준이라지만, 그래도 나름 '생각' 이라는 것을 해보면서 쓰고있다. + 플레이리스트에 아이묭(aimyon) 노래를 틀면서 하기 시작했는데, 기존에 듣던 재즈보다 힘차게 하는 느낌이다(TMI) 기존에, 회원가입 로직을 위해서 Member -> MemberRepository(+MemberCustomRepository) -> MemberService -> MemberController RefreshToken -> RefreshTokenRepository -> RefreshTokenServie -> RefreshTokenController 로 만들려던 계획을 조금 수정했다. DDD라는 것을 조금 찾아보면서, Member,..

이전에 null값으로 인한 예외가 발생되는 것을 컨트롤러 테스트를 만들어 검증해보았다. 이번엔, 중복 발생시 / 비밀번호가 서로 다를 시 / 이메일이 형식에 맞지 않을 시 를 검증할 것이다. 일단 중복이 발생하기 위해서는, 몇가지 선행되어야 할 내용이 있다. 매 순간 비교하기 위한 데이터 하나와, 기존의 데이터가 있어야 한다. 매 단위테스트마다 db를 초기화시켜 다른 테스트가 영향을 받으면 안된다. 이런 점을 맞추기 위해, 테스트를 실행하는 RegisterRequestDto를 반환하는 로직을 하나 만들었다. private static RegisterRequestDto makeTestRegister() { return RegisterRequestDto.builder() .username("test") .n..

이제 컨트롤러를 좀 만들어보며, 테스트도 해보려고 한다. 일단 제일 간단한 회원가입 로직부터 만들고, 테스트를 해봐야겠다. @RestController @RequiredArgsConstructor public class MemberController { private final MemberService memberService; @PostMapping("/join") public String register(@RequestBody @Valid RegisterRequestDto registerRequestDto){ memberService.registerNewMember(registerRequestDto); return "success register"; } } 간단하게 만들었다. 일단, RegisterR..

제목에서 보는 그대로의 목표를 위해 테스트코드로 검증을 해보려고 한다. 일단, and를 이용했을 경우, 검색하는 값이 testUser1을 목표로 하는 파라미터와, testUser2를 목표로 하는 파라미터라면, 검색시에 아무것도 나오지 않는다. 하지만, or과 contains를 입력하면 SearchMemberDto에 username = "11", nickname = null, email = "22"로 검색하면 11, 22번의 두 멤버가 나와야 한다. 이게 잘 이루어지는지 확인해보고 싶었다. @Test @DisplayName("") public void 서로_다른_객체를_요구하며_검색하기() throws Exception{ //given SearchMemberDto searchMemberDto = new S..

Source Code : https://github.com/JangAJang/Algorithm/blob/main/프로그래머스_Lv2/전력망을%20둘로%20나누기/src/Solution.java https://school.programmers.co.kr/learn/courses/30/lessons/8697 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 문제의 링크는 여기 있다. 완전탐색의 문제였지만, 완전탐색 하나만 생각해서 풀지 않았던 것 같다. 완전탐색으로 각 경우에 탐색할 때, dfs를 사용했으니 틀린말은 아니겠지...?? 일단, 문제를 어떻게 풀지를..

저번의 생각을 토대로, 조금 더 최적화를 해보려고 했다. 일단 처음의 코드를 보자면, private BooleanExpression usernameEq(String username, SearchType searchType){ if(username == null || username.isEmpty() || username.isBlank()) return null; if(searchType.equals(CONTAINS)) return member.username.contains(username); return member.username.eq(username); } private BooleanExpression nicknameEq(String nickname, SearchType searchType){ if..

일단 MemberService를 다시 돌아보았다. validate / domain logic / repository사용을 최대한 분리해 각 메서드를 register에서 7줄 정도를 만든게 최대 길이일 정도로 최대한 잘게 나누어 사용해보았다. 이렇게 되면서, 메서드 재사용성을 확인하고, 각 로직에서 에러가 발생했을 때, 어떤 이유인지 확인하기 용이했던 장점이 있다. 또한, 로그인 로직에서 Token까지 MemberService로 묶었을 때 하나의 서비스까지 두개의 도메인을 따로 가져와 다 사용한다는게 조심스러웠는데, 이 부분을 나누는데 시간을 많이 쓴 것 같다. 원래 도메인 로직밖에 테스트할 줄 몰랐는데, 이번에 리포지토리, 서비스 테스트에 대해서 연습해보고 적용해볼 수 있어 더 좋았다. 개인적으로 컨트롤..

private static final PageRequest page = PageRequest.of(0, 3); search 하나로 더욱 다양한 기능을 만들 방법을 생각해보았다. 페이징을 추가하자 RequestParam방식으로 페이지를 입력받아 몇 번째 페이지인지를 알려줄 것이다. 한 페이지당 기본으로 10개정도의 결과를 가지게 반환시킬 계획이다. 멤버 조회시 아이디, 닉네임, 이메일이 나오므로 총 30줄정도가 나올 것 이므로 10개 정도가 적당하다는 생각이 들었다. contains를 동적으로 추가하자 enum클래스를 만들어 RequestParam으로 검색방식을 정확한 검색인지, 혹은 검색하는 문구가 포함된 값을 구하는지를 정하게 할 것이다. 이전에 만들었던 ~~Eq메서드에 enum타입의 값을 받아 만약 ..

이번 프로젝트에서 jwt토큰을 이용해 로그인을 하게 하려고 했다. 이를 위해서 두가지 과정이 필요하다 로그인 요청을 이용해 Authentication을 만든다. 로그인 요청을 validate한다 요청의 아이디와 비밀번호를 가지고 UsernamePasswordAuthenticationToken을 만들어준다. 토큰에서 authentication을 뽑아온다. Authentication을 가지고 토큰을 만들고, 토큰 응답을 반환한다. TokenProdivder에서 Authentication을 가지고 TokenDto를 생성해준다. authentication에서 name(아이디)를 key, TokenDto의 refreshToken을 value로 가지는 RefreshToken객체를 만들어 저장한다. 이를 TokenR..