일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 일상
- 공룡책
- Test code
- db
- proxyFactory
- 소프티어
- ExceptionResolver
- mapstruct
- 갓생
- Test
- Test Doulbe
- softeer
- modelmapper
- FCM
- 테크쇼
- Coputer Science
- 2025 계획
- enumSet
- OS
- Java
- 2024회고
- 직장인 회고
- JPA
- MySQL
- Service 계층 테스트
- 자바
- Spring
- Server
- 인프콘2023
- Junit 5
- Today
- Total
목록Spring (16)
공부내용공유
서론 스프링 Proxy를 공부하면서 Proxy Factory 에 대해 알게되었다. Proxy Factory는 interface 를 구현하고 있는 class 의 경우에는 JDK 동적 프록시를 사용해서, interface 를 구현하고 있지 않은 경우에는 CGLIB 를 사용해서 프록시를 만들어 주는 식으로 동작한다. Proxy Factory 가 어떻게 이를 구분하고 어떤식으로 proxy 객체를 만드는지 궁금해서 코드를 직접 보면서 간단하게 정리하였다. 본론 프록시 팩토리를 생성하고 해당 팩토리에서 프록시를 가져오는 코드를 먼저 살펴보면 프록시 대상으로 삼을 클래스를 정해준다. ProxyFactory 생성자에 해당 클래스를 넣어서 proxyFactory 를 생성한다. 해당 Factory 에 사용하고 싶은 프록시..
서론 처음에 프로젝트를 시작할때는 예외처리에 대해 깊게 고민하지 않고 비즈니스상 발생하는 Custom Exception 만 만들고 던지면 충분하겠지 라고 생각을했다. 그러나 실제 프로젝트를 진행하면서 client 개발자분은 다른 예외들을 더 많이 마주쳤고 해당 예외에 대해서는 별도의 처리가 안돼있어서 어디서 잘못된건지 알아볼 수 없는 형태였다. 예외가 터질때마다 연락을 하여 물어보는 비효율적인 방식을 개선하기 위해 위해 예외처리에 대해 알아보고 프로젝트에 적용을 하고 어떻게 더 개선할 수 있을까에 대한 고민을 글로 작성하였다. 본론 프로젝트를 진행하면서 client 개발자 분이 가장 자주 마주치는 Exception 들은 MethodArgumentNotValidException HttpMessageConv..
서론 Repository 계층 테스트 코드를 작성할때 처음에는 어플리케이션에서 사용중인 MySQL DB를 그대로 사용하였다. 그러다가 한 테스트에서 로컬에 저장되어 있던 데이터에 의해 테스트가 실패하였고, 물론 값을 바꿔주면 테스트를 통과하긴 하겠으나 이 테스트가 다른 사람 pc에서 안깨지려면 테스트 DB를 분리하는게 맞겠다는 생각이 들었다. Spring 으로 프로젝트를 진행할때 local DB 나 Test DB 로 H2 를 많이 사용하기에 나도 H2 DB 로 설정을 바꿔주고 테스트를 돌렸다. 그런데 잘만 돌아가던 테스트들이 깨지는 케이스가 발생했다. 이를 기억하고 앞으로 코드를 작성할때 주의해야겠다는 생각이 들어 이 글을 작성하였다. 본론 테스트가 깨진 경우는 2가지 였다. native query 사용..
서론 현재 진행중인 프로젝트에서 잘만 돌아가던 API 가 안된다고 프론트 팀원분에게 연락이 왔고 나는 로그를 보고 오류를 확인을 했는데 다름이 아닌 다른 파트를 맡은 친구가 자신의 파트에서 기능 일부분을 수정했고 자신의 파트만 되는지 시행해 보고 PR 을 넣었던 것이다. 나도 그냥 기능을 수정했나 보다라고 간과하고 PR을 받았고 그 결과 내가 만들었던 API가 영향을 받아 오류가 났던것이다. 이를 경험하고 Test Code 의 중요성을 깨닫고 PR 을 넣을때는 적어도 Unit Test 는 모든 파트에서 돌려보고 넣는게 맞겠구나 라는 생각이 들어 Test Code 를 작성하게 되었다. 본론 Service 계층에서의 Test Code 를 먼저 작성하였다. 이 글에서는 내가 진행한 프로젝트에서 Junit 5 ..
서론 현재 진행중인 프로젝트에는 주요 Domain은 강의 와 강사이다. 이 두 도메인은 필드 들도 많고 다양한 화면에 노출되고 다양한 로직에 사용이된다. 기본적인 Create, Update를 위한 dto들도 당연히 있지만 제일 많은것들은 Read에 관련된 Dto들이다. Dto들에도 굉장히 많은 filed들이 있고 처음에는 entity 에서 dto를 만들때 builder 패턴을 사용해서 하나하나 다 코드를 쳐서 만들었다. 그러나 프로젝트를 진행하면서 디자인이나 기획이 바뀌는 경우가 종종 있었고 이때마다 entity에도 정보가 추가되는 경우도 있었다. 이때마다 모든 builder를 돌아다니면서 하나하나 추가하는것은 잦은 실수를 유발했고 이를 어떻게 해야하나 고민하면서 Mapper에 대해 알게 되었다. 본론 ..
서론 현재 프로젝트에서 Service 계층 테스트를 service 계층은 2개의 계층과 연결되어 있는만큼 굉장히 다양한 기능들에 의존을한다. RDB connection, 데이터 세팅, Mapper, Spring context 등등 구글링을 했을때 spy, mock 등등 다양한 어노테이션을 사용하는것을 보았는데 정확히 어떤 역할을 해주고 어떤때 사용해야하는지 몰라서 이를 정리하기 위해 이 글을 작성하였다. Test Double test double이란 테스트 하려는 코드 부분을 제외한 나머지 코드로부터 영향을 받지 않고 테스트를 진행하기 위해 가상의 객체를 생성하여 주입하는것을 말한다. Test Double을 통해 테스트에 의존적인 객체, DB, 여러 설정 정보들로부터 격리시켜 테스트 속도를 높일 수 있다..