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

사실 검색에 대한 테스트코드를 만드는 것은 간단하다. 리포지토리 테스트코드에서, 기능들을 그대로 가져다 쓰는 것과 동일하다 . @BeforeEach void createData() { for(int index = 0; index < 10; index++){ RegisterRequestDto registerRequestDto = RegisterRequestDto.builder() .username("testUser" + index) .nickname("test" + index) .email("test" + index + "@test.com") .password("password" + index) .passwordCheck("password" + index) .build(); memberService.reg..

일단 정보 수정을 수행하는 로직의 테스트부터 만들어볼 것이다. 닉네임 수정 닉네임 중복으로 예외처리 정상적으로 수정 이메일 수정 이메일 중복으로 예외처리 정상적으로 수정 비밀번호 수정 기존 비밀번호와 동일해 예외처리 입력한 비밀번호 2가지가 서로 불일치 정상적으로 수정 이렇게 총 3가지의 수정 메서드와, 각 메서드당 2(비밀번호는 3)가지 경우가 생기게 된다. 결국 7가지 테스트를 만들어두고, 이에 대해 기능을 수행하는 메서드를 만들어보려고 한다. private Member makeMember(String index){ RegisterRequestDto registerRequestDto = RegisterRequestDto.builder() .username("test" + index) .nickname..

이전에 만든 테스트가 동작하게, 하나씩 만들어보아야 겠다. 일단, 아이디 중복을 처리했을 때 동작하는지 코드를 만들어보자. private void validateUsername(String username){ if(memberRepository.findByUsername(username).isPresent()) throw new UsernameAlreadyInUseException(); } 이런식으로 중복이 되는 것을 닉네임, 이메일에도 처리해주었다. validateUsername(registerRequestDto.getUsername()); validateNickname(registerRequestDto.getNickname()); validateEmail(registerRequestDto.getEma..

이제 리포지토리에서 구현했던 기능들과, Member 도메인 로직을 이용해, 멤버의 서비스를 구현할 것이다. 도메인 로직과 리포지토리의 기능들을 이용해, 실제 멤버가 동작해야 할 비즈니스 로직을 만들어볼 것이다. 구조를 생각해보기 위해 회원가입을 생각해보자. 입력을 받는다. 중복 계정을 조회한다. 중복 닉네임을 조회한다. 중복 이메일을 조회한다. 비밀번호를 2번 입력받았을 때 이를 확인한다. 비밀번호를 암호화 시켜준다. 입력으로 Member를 생성해준다. MemberRepository.save해준다. 이런 방식으로 이루어진다. 그렇다면, 회원가입을 했을 때 문제가 생길 결과는 무엇일까? 입력값이 다른 회원과 중복될 때, 예외처리된다(아이디, 닉네임, 이메일 예외를 모두 따로 설정해준다) 비밀번호 입력이 서..

이전에 만든 검색기능을 조금 더 최적화 시켜야 할 필요가 있다. 이러한 생각이 든 이유는, 멤버를 검색하는 기능에서 엔티티가 바로 클라이언트 단으로 나가도 괜찮을까? 일반 사용자가 다른 사용자를 검색했을 때 나와야 할 것은 기본적인 정보(아이디, 닉네임, 이메일)외에 다른 게 없는데 굳이 많은 데이터를 끌어올 필요가 있을까? 정도였다. 그래서, 이번엔 바로 dto로 데이터를 검색시키는 방법으로 최적화를 시키려고 한다. 일단, @QueryProjection public SearchMemberDto(String username, String nickname, String email) { this.username = username; this.nickname = nickname; this.email = ema..

저번에 만든 QueryDsl을 어디에 써먹는지, 이제 적어볼 생각이다. 저번에 만든 MemberCustomRepositoryImpl의 search를 전부 지워버렸다. 이후, QueryDsl을 위해 만들어야 할 것들을 정리해보았다. JPAQueryFactory 인스턴스를 초기화 하는 생성자 search : 아이디, 닉네임, 이메일을 가지고 검색을 수행한다. null값은 스킵한다. usernameEq : 아이디가 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. nicknameEq : 닉네임이 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. emailEq : 이메일이 null이면 null을 반환하고, 아니면 쿼리문을 반환한다. 이제 이걸 만들어보자. public class Member..

실질적으로 지난 블로그 공백기(!) 중에 제일 공부하기 잘했다고 생각이 드는, queryDsl을 설정해줄 것이다. 일단 build.gradle에 이러한 의존성과, 설정 주입을 해주어야 한다. buildscript { ext { queryDslVersion = "5.0.0" } } plugins { id 'java' id 'org.springframework.boot' version '2.7.0' id 'io.spring.dependency-management' version '1.0.11.RELEASE' id "com.ewerk.gradle.plugins.querydsl" version "1.0.10" } 제일 위에 queryDslVersion을 적어주고, plugins에 마지막줄에 queryDsl을 넣..

저번에 만든 멤버 리포지토리를 가지고, 이제 새로운 기능들을 주입시켜볼 것이다. 기본적으로 메서드의 이름을 가지고 생성, 조회, 삭제를 할 수 있다. 그러면 조회하는 요소를 이름, 이메일, 닉네임중에 몇개를 골라서 수행하는, 동적 방식의 조회는 어떻게 할까? 이걸 JPQL(노가다)로 한번 만들어보고, 테스트를 수행시켜보고, QueryDSL을 통해 업그레이드 시켜볼 계획이다. 일단, 검색을 시켜줄 dto와 예외처리부터 만들었다. @Data public class SearchMemberDto { private String username; private String nickname; private String email; public SearchMemberDto(String username, String n..

일단 클래스를 만들었다. @SpringBootTest는 이 테스트가 스프링 부트 상에서 돌아간 다는 것을 의미하고, @Transactional은 해당 클래스가 트랜잭션을 만듦을 의미한다. 일단 C, R, U, D를 다 테스트해보아야 하는데, 생각해보면, 만든게 조회가 제대로 되면, 내 머리같이(?) 비어있는 데이터베이스에 데이터가 생기는 것이다. 즉, 생성은 테스트하지 말고, 그냥 생성시키는 로직을 만든 뒤, 조회를 시키면 되는 것! 그래서! @Autowired private MemberRepository memberRepository; @Autowired private EntityManager em; @BeforeEach public void initData(){ RegisterRequestDto re..

사실 게시판 만들기를 하다가 대략 2~3주 정도를 쉰 것 같다. 이유인 즉슨, 리포지토리를 테스트하는 방법을 찾다가 여러 강의들을 찾게되었다. 공부하다가 로드맵? 이라는 게 있었다. 로드맵을 보니까 또 이게 다 뭔지 알고싶었다 (또 호기심이 미쳐 날뛰어 버렸다) 그래서 이제 할 수 있겠냐고? ㅆㄱㄴ 가능하니까 이제 다음 과정들을 써보려고 한다. 일단 리포지토리의 기본적인 기능들을 만들어볼 생각이다. 우리가 백엔드 프로그래밍을 배우면 기본적으로 CRUD라는 것을 듣게 된다. Create Read Update Delete 이렇게 4가지가 존재한다. 이에 대한 기능들을 Spring Data JPA에서 지원하는 리포지토리를 이용해 만들어보려고 한다. package com.board.Board_Upgraded.r..