CSR 기반 JUnit5 Bank-Application
1.Junit Test Application-1-의존성추가
의존성 추가패키지 구조
2.Junit Test Application-2-yml 세팅
application-dev.ymlapplication-prod.ymlapplication-test.ymlapplication.ymldev로 되어있으면 application-dev를 읽는다.
3.Junit Test Application-3-UI 설계
4.Junit Test Application-4-테이블 설계
users_tbaccount_tbtransaction_tb
5.Junit Test Application-5-Entity 설계
UserUserEnumBankApplication@EntityListeners(AuditingEntityListener.class)가 있어야 밑에 붙인 createAt, updateAt 이 자동으로 insert, update가 된다. 추가로 BankApplication
6.Junit Test Application-6-SecurityConfig 세팅
시큐리티가 되어있지 않은 상태logger 부분은 @Slf4j를 사용해도 되지만 이럴 경우에는 JUnit 테스트를 할 때 문제가 발생한다.@Bean을 등록하면 IOC에 등록이 된다. 따라서 BCryptPasswordEncoder를 객체로 등록을 한다. 단 @Configu
7.Junit Test Application-7-SecurityConfig 설정 테스트
코드 추가디버그로 순서 확인context에는 스프링으로 등록된 모든것들이 String\[] 상태로 존재한다.ioC에 등록된 것들 확인포스트맨으로 확인 403이 뜨니까 시큐리티가 잘 설정이 되어있는지 알 수 있다.
8.Junit Test Application-8-SecurityConfig JUnit 테스트
이 부분에 대한 테스트, Junit, 포스트맨, 웹 전부 다른 형태로 나온다. 일관성 없음따라서 SecurityConfig에 Exception 제어권을 가져오기누구의 제어권을 가져오냐? authenticationEntryPoint가 파라미터로 받는 값의 타입이 Auth
9.Junit Test Application-9-공통 DTO 생성
dto 추가코드 수정하지만 코드를 해당위치에 두면 재사용성 낮음, util 패키지 생성후 코드 생성try - catch 로 묶는 이유 : 파싱할 떄 에러 발생할 수 있어서그리고 SecurityConfig 수정테스트를 통해 일관성 있게 에러가 리턴내가 모르는 에러가 FE
10.Junit Test Application-10-회원가입 서비스 만들기
레포지토리 만들기서비스에서 코드 작성하기서비스에서는 DTO를 받아서 DTO를 내보내는 것을 고정으로findByusername에 대한 코드 작성, \* 네임드 쿼리 찾아보기 네임드 쿼리void findByUsername(String username);예외처리하는 핸들러
11.Junit Test Application-11-회원가입 서비스 JUnit 테스트
서비스 테스트 코드이전에 했던 통합 테스트와는 다른 어노테이션을 필요로한다. 주의하고 차이점을 이해하자. 서비스 테스트의 경우는 가짜환경에 넣는 것이다.실행하면 null이 뜬다왜냐하면 Mock 환경에는 Spring 빈들이 존재하지 않기 때문이다. 따라서 등록을 해줘야한
12.Junit Test Application-12-회원가입 서비스 리펙토링
서비스 코드에 있는 DTO 옮기기userDTO 2개 생성테스트 할때마다 stub 부분에 User를 빌더로 작성하는 거 불편 따라서 Dummy를 만들기newUser는 진짜로 DB에 들어가는 것이기 때문에 id, 2개 날짜 필요없음하지만 newMockUser는 오직 테스트
13.Junit Test Application-13-회원가입 컨트롤러 만들기
컨트롤러 작성스프링 부트 기본전략은 x-www-form-urlencoded 에서 JSON으로 바꾸기 (+ @ReuqestBody)만약 비밀번호가 길어져도 들어감 따라서 제한을 걸어야한다. 유효성 검사 처리컨트롤러 수정Dto에 @NotEmpty 의 어노테이션에서 에러가
14.Junit Test Application-14-회원가입 컨트롤러 AOP 처리, 유효성 검사
AOP 개념 정리와 유효성 검사의 중요성AOPpointcut : 어떤 메소드에 자동으로 adivce코드를 구현하고 싶은데?advice : 어떤 코드를 구현할 건데?joinpoint : pointcut 어노테이션이 붙은 메소드들 의미@Around : 이거일 경우만 Pro
15.Junit Test Application-15-회원가입 컨트롤러 정규표현식과 Dto 적용
정규표현식 자료dto에 정규표현식 적용정규표현식 학습
16.Junit Test Application-16-회원가입 컨트롤러 JUnit 테스트
아직 전체 테스트를 하면 실패가 나올 것이다. 왜냐하면 DB에 들어갈 떄 자동 PK 증가 전략을 사용하지 않았기 때문이다. 각각 돌려야 한다.
17.Junit Test Application-17-jwt 세팅
jwt 설명jwt는 무상태 서버 -> jSessionId 사용X -> 토큰을 사용서버에서 HS256을 이용해 암호화 후 토큰을 생성, 토큰 전달FE에서는 토큰을 들고 항상 접근 -> 토큰을 검증따라서 RSA 방식이 아닌 대칭키 사용InternalAuthenticatio
18.Junit Test Application-18-jwt 필터 세팅
Junit Bank Application 깃허브 Junit Bank Application 기록 노션
19.Junit Test Application-19-jwt 필터 등록
저번에 JwtAuthenticationFilter를 만들었으니까 등록을 해야한다.SecurityConfig 추가필터를 등록할 때, new JwtAuthenticationFilter() 안에 authenticationManager를 넣어줘야 한다. 왜냐하면 이전 18장에
20.Junit Test Application-20-jwt 로그인 실패 로직 처리
JwtAuthenticationFilter 코드 수정공통 형태로 나온다.
21.Junit Test Application-21-jwt 인가 필터 세팅 및 등록
SecurityConfig 추가UsernamePasswordAuthenticationToken에서 첫번째 매개변수는 UserDetails or username 타입만 가능하다.테스트베리어 토큰404, 필터 통과하고 컨트롤러까지 갔다는 의미, 즉 인증 그리고 권한 통과a
22.Junit Test Application-22-jwt 개념 이해
차이점강제로 Authentication을 만드는가?O : 인가(강제로 로그인 후 Authentication에 넣기)X : 인증(UserDetailsService 이용)JWT는 stateless 이기 때문에 request하고 response하는 순간 세션이 비워진다.
23.Junit Test Application-23-JwtProcess JUnit 테스트
JwtProcess의 create와 verify를 테스트하자업로드중..
24.Junit Test Application-24-successfulAuthentication JUnit 테스트
실핼 시 오류 발생 -1 발생이유 : ssar이 DB에 존재 X동작 순서 확인successfulAuthentication 발동강제로그인 발동 -> UserDetailsService를 구현한 LoginService 발동이때 Username을 넣는데, username이 없
25.Junit Test Application-25-unsuccessfulAuthentication JUnit 테스트
코드 추가하지만 전체를 돌리면 터진다.왜냐하면 각각의 테스트를 돌릴 때마다. @BeforeEach가 발돌하기 때문이다. 이때 테스트는 독립적으로 수행되야하기 때문에 순서가 중요하지 않다. 따라서 테스트마다 롤백이 되야한다.각 테스트가 진행되고 끝날때마다 롤백이 된다.
26.Junit Test Application-26-Authorization JUnit 테스트
코드authorization_admin_test 실행하면, SecurityConfig 의 아래 부분에서 걸린다.모든 인증과 인가에러의 제어를 우리가 했다.
27.Junit Test Application-27-회원가입 테스트 오류
전체를 돌리니까 해당 부분에서만 터진다.이유는 롤백이 되지않아서이다. 따라서 @Transaction을 추가해주자업로드중..
28.Junit Test Application-28-계좌등록 기능
계좌등록 서비스 코드이제 컨트롤러 코드를 만들어보자LoginUser 에는 id, role 만 존재 : JwtAuthorizationFilter 확인DTO의 경우는 dto로 옮기기이거를 POST맨으로 하려면 회원가입 로그인 까지 항상 해야하기 때문에 너무 귀찮다. 따라서
29.Junit Test Application-29-계좌등록 JUnit 테스트
로그인을 하면된다.우리가 JWT로 로그인을 할 필요가 없다. JWT token -> 인증필터 -> 시큐리티 세션 생성즉 /api/s/account는 시큐리티 세션만 있으면 통과가 가능하다는 것이다."로그인을 진행해 주세요" 이부분은 SecurityConfig에서 터진
30.Junit Test Application-30-본인계좌목록보기 기능
서비스 코드stream -> map -> collectAccount에 User가 잊지만 LAZY 로딩하지 않는 이유 : 굳이 할 필요가 없어서 왜냐하면 user_id로 account를 조회하기 때문에컨트롤러 코드/s/account/{id} 이렇게 작성할 경우 권한 처리
31.Junit Test Application-31-본인계좌목록보기 JUnit 테스트
어차피 Repo 테스트가 아니니까 stub을 2개를 걸어준다.컨트롤러 테스트본 코드를 보면 파라미터값이 @AuthenticationPrincipal LoginUser loginUser 이기때문에 아무것도 존재하지 않는다.
32.Junit Test Application-32-계좌삭제 기능
서비스 코드컨트롤러 코드여기서 주목할 점은 accountPS.checkOwner(userId); 이렇게 작성한 것
33.Junit Test Application-33-계좌삭제 기능JUnit 테스트
서비스 테스트 코드컨트롤러 테스트 코드쿼리를 보자2개의 insert, ssar cosaccount 2개 insert1번쨰 select는 @WithUserDetail 때문에 발생2번쨰 account를 selectaccount 서비스를 가보면쿼리 비교Account의 use
34.Junit Test Application-34-@Sql.teardown
원리 이해테스트 클래스에 @Transactional을 붙였다. 그러면 각 테스트들은 독립적으로 실행이 된다. 하지만 각 테스트전에 실행되는 setUp()은 N개의 테스트개수 만큼 실행이 된다.그러면 setUp()에 ssar, cos를 insert하는 쿼리가 있다고 생각
35.Junit Test Application-35-JWT 만료시간 버그 잡기
만료시간이 끝나서 보니까 에러가 발생했다. 다음과 같이 코드를 수정했다.
36.Junit Test Application-36-계좌입금 기능
서비스 코드dto컨트롤러 코드포스트맨 테스트를 위한 더미 수정유효성 검사
37.Junit Test Application-37-계좌입금 기능 JUnit 테스트
더미 데이터서비스 테스트 코드이유 생각테스트 할때는 꼬이기 때문에 그냥 각각의 stub을 작성할 때는 새로 만들자즉, 스텁이 진행될 때마다 연관된 객체는 새로 만들어서 주입하기 - 타이밍 때문에 꼬인다.완성 코드계좌입금 서비스 테스트에 대한 고찰0원 체크deposit
38.Junit Test Application-38-계좌출금 기능
서비스 코드dtoaccount주목할 점 : long 비교시 longValue()로 비교컨트롤러
39.Junit Test Application-39-계좌출금 기능 JUnit 테스트
서비스 테스트컨트롤러 테스트
40.Junit Test Application-40-계좌이체 기능
서비스dto컨트롤러
41.Junit Test Application-41-계좌이체 기능 JUnit 테스트
서비스 테스트컨트롤러 테스트만약 테스트할 때 400이 뜬다면 ResponseDto 가서 @JsonIgnore가 값을 받는지 확인
42.Junit Test Application-42-CORS 확인
configureation.addEposeHeader("Authorization");없는 경우있는 경우Access-Control-Expose-Header의 여부따라서 CORS 허용을 해야한다.
43.Junit Test Application-43-입출금내역 JPQL 동적 쿼리 체크
디폴트 : 전체 내역 가져오기입금 click : 입금에 관한 내용만 가져오기출금 click : 출금에 관한 내용만 가져오기동적쿼리로 해결!interface 추가 및 구현추상적인 것에 의존하는 완벽한 코드 ㅎㅅㅎ물론 TransactionRepository에 바로 작성하고
44.Junit Test Application-44-left join(left outer join)하는 이유
JPQL 이면 left join, native 쿼리면 left outer join게시글 목록 보기에서 left join(left outer join)이면 일단 Board의 모든 내용을 뿌린다. 그러면 모든 Board를 가져오고 Board에 빈 값이 있는 경우 전부 nu
45.Junit Test Application-45-@DataJpaTest 더미테이터
더미데이터 추가 및 @DataJpaTest 추가 및 테스트 코드 추가레포지토리 테스트를 할 것이기 때문에 해당 부분만 띄우면 된다. @SpringBootTest를 띄워서 전체를 Mock에 할 필요가 없는 것. 결론 : @DataJpaTest -> DB와 관련된 Bean
46.Junit Test Application-46-@DataJpaTest autoincrement 초기화
1 ~ 10 까지 계속 증가, 테스트가 2개로 분리되어 있는데도JPA 테스트 할 때는 truncate를 사용 못함, 즉 아래의 코드(@Sql)를 사용하지 못하는 것JPA 테스틑 자동 truncate가 되지 않기 떄문에 직접 nativeQuery로 작성해서 초기화 시키기
47.Junit Test Application-47-@DataJpaTest 더티체킹
순서도(노란색)전체 목록보는 테스트 코드쿼리체크update가 날라가는 이유는 더티채킹이 되지 않아서 우리가 따로 save한 것 때문에한방쿼리 left outer join을 사용했기 때문에, 동적쿼리 사용된 것더티채킹 하기다음과 같이 주석 처리 후 실행이걸로 알 수 있는
48.Junit Test Application-48-동적쿼리 테스트
1, 3, 4번이 출금이 뜻은 withdraw_account_id 가 1, 3, 4번 인 것만 나왔다는 것, deposit_account_id 주황색은 입급을 받은 것5번만 입금1, 3, 4, 5번 전부 나온다.1번째 left join fetch -> join fetc
49.Junit Test Application-49-fetch join 테스트
한방 쿼리를 통해 코스 출력근데 한방 쿼리를 보면 transaction, account 까지는 가져왔는데 user는 가져오지 않았다. 이러면 안되기 때문에 영속성 컨텍스트를 비워줘야한다.실행getBalace() 추가 후 실행추가 쿼리 없이 inner join fetch
50.Junit Test Application-50-입출금내역 기능
서비스 코드dto컨트롤러 테스트아래 2개의 경우 모두 가능 알아서 선택
51.Junit Test Application-51-입출금내역 기능 JUnit 테스트
서비스 테스트, X서비스 테스트의 경우 할게 없다. 왜냐하면 Repossitory에서 가져오는 것들은 서비스단에서 테스트하는 것들이 아니여서 stub이 사용이 되고, checkOwner() 같은 경우는 이미 기존에 테스트로 검증이 되었기 때문에 할 필요가 없다.따라서
52.Junit Test Application-52-계좌상세보기 기능
Junit Bank Application 깃허브 Junit Bank Application 기록 노션 account 조회 1번, 동저쿼리 조회 1번 서비스 코드 dto 컨트롤러 코드
53.Junit Test Application-53-계좌상세보기 기능 JUnit 테스트
서비스 테스트 코드없음, 이유는 입출금목록과 동일한 이유컨트롤러 테스트(select 2번)더미데이터 추가하기
54.Junit Test Application-54-외래키 제약 조건 에러 DataIntegrityViolation
전체 테스트 중에서 유일한 에러DataIntegrityViolation 에러외래키 에러가 발생해서 생긴 에러따라서 FK제약조건을 해제 -> 데이터 무결성 지킴
55.Junit Test Application-55-dev 모드 더미데이터 추가 후 POSTman 실행(끝)
Junit Bank Application 깃허브 Junit Bank Application 기록 노션
56.Junit Test Application-56-추가해야할 사항
RestDoc 문서 추가 후 REST api 문서 생성CI/CD 추가Sentry 추가Error 테이블 추가, 어노테이션 붙이기ERD 설계도 깃허브 추가시스템 구성도 깃허브 추가커밋 일지 추가