본문 바로가기

백엔드62

테스트 2 * 코로나 줄서기 프로젝트 활용 @SpringBootTest 기본 에플리케이션 context load(통합 test시 사용) bootstrap with + extendwith value와 properties = {}로 직접 설정. args -> 직접 실행하는 command . WebEnvironment.Mock,None(은 tomcat이 실제로 돌지 않음) .RANDOM_PORT,DEFINED_PORT는 직접 TOMCAT이 돈다. 스프링에서 제공하는 Auto-configured Test 한 가지 예시 @WebMvcTest . mockmvc 빈을 자동 설정하고 사용한다. (복습하자, mock mvc는 마치 http가 request한것처럼 따라하는 역할을 한다.) 일단 perform은, exception을 .. 2024. 1. 3.
ERROR 처리 WHITELABEL ERROR PAGE를 .. 당연히 매우 자주 봤다. server.error.whitelabel.enabled=false 로 WHITELABEL을 제거하고 사용할 수 있고, 그런 경험도 실제로 존재한다. (CONTROLLER를 ERRORCONTROLLER를 IMPLEMENTS 받아, 사용해야한다.) CLIENT가 SERVER에게 REQUEST할떄, ACCEPT라는 헤더가 있다.(나 CLINET는 이런 JSON,XML등으로 보내줬으면 좋겠어 하고 힌트를 주는 헤더 ) BROWSER는 기본이 TEXT.HTML -> 기본적으로 ACCEPT HEADER를 전송할 수 있다. 이러한 기본 WHITELABEL에, PROPERTIES에 MESSGAE,STACKTRACE등을 켜서, WHITELABELP.. 2024. 1. 2.
Handler Methods 요청과 응답을 진행한다. @RequestMapping -> template 엔진을 사용해야만 (Thymeleaf)의미가 있다. 지정해서 요청의 응답을 변경할 수 있다. Mapping annotation에서, value = "/어쩌구", name = "내가 지정해주는 이름" 인데, 저절로 생성해준다. (겹칠때 회피가 가능하다) headers = "header-auth =~~" 등, 특정 header의 요청에 대해서만 반응하게 만들 수 있다. consumes -> json 데이터 요청만을 받는다. 요청 httpSession,ServletRequest,등을 받을 수 있는 요청이 된다. @RequestBody , @PathVariable, @RequestParam등을 사용할 수 있다. 수 많은 요청이 있다. 응.. 2024. 1. 2.
추가 기술들 Lombok 엄청나게 자주 사용했던 도구이다. Lombok이 없다면? 1 . 변수 생성 2. getter setter 생성. 3.메소드 생성 4. 로그 출력 구현을해준다 @ToString 5.builder로 바꿔달라.. 너무 많은 변경 필요 . Lombok이란 , 동일한 코드를 ( 보일러 플레이트를) 다시 절대로 작성하지 않겟다. 즉, 생산성 도구라고 볼 수 있따. 이미 builder로 구현이 되어있고, eqaul도 되고, tostring도 다 되어버리네? -> lombok이 해준다 접근자 설정을 내가 해주지 않아도 된다 . spring initalizer로 간단하게 사용할수있따. 인기 기능 1. @Data getter+setter+requiredargsconstructor(생성자 중에 필수필드(fina.. 2024. 1. 1.
BOOT의 기능 1. BOOT PROPERTIES -> 대부분의 기능을 제어할 수 있다. 혹시 진행하다가보니, 계속 자바의 PROPERTIES를 사용한다? 재 확인이 필요하다 . application properties의 debug = True : debug log를 추가한다 . 빈임을 등록해줄때는 @Configuration이 필요하다. dlfmf @Component로 알아서 찾게끔 해주면, 기본적으로 controller,service,repository등을 모두 찾아줄 수 있다. cache등도 지원한다. data 관련에서는 enable등을 사용 가능하다. 상황에 따라 검색하고, properties를 검색하여 사용하자 . #component or service, controller등의 어노테이션을 쓴다. dto나 ent.. 2023. 12. 30.
스프링과 스프링 부트의 차이/ 스프링만 사용했을때의 불편함. 가장먼저, SPRING과 SPRING BOOT의 차이를 알고 가자 . 스프링(Spring)은 프레임워크이며, 스프링 부트(Spring Boot)는 스프링 프레임워크를 기반으로 한 도구입니다. 스프링은 설정 파일을 작성해야 하지만, 스프링 부트는 자동 설정을 제공하여 간편하게 개발할 수 있습니다. 또한, 스프링 부트는 내장 서버를 제공하여 쉽게 웹 애플리케이션을 실행할 수 있습니다. Spring은 스프링 프레임워크를 보다 세밀하게 제어하고자 하는 경우에, Spring Boot는 빠르고 간단하게 스프링 애플리케이션을 개발하고자 하는 경우에 사용됩니다. -SPRING 사이트 참고. 사실 BOOT를 기본적으로 사용해왔기 때문에, 추가적인 개념을 공부하는 위주로 공부에 임하자. ++전자정부 프레임워크가 스프링 기.. 2023. 12. 30.
완성한 개발자 저장 프로젝트를 통해 핵심 복습 핵심 내용을 복습해보겠다. 프로젝트 -> 클론프로젝트 -> 개발자 프로젝트에 있는 내용을 기반으로 복습을 진행하겠다. 1. DI, IOC 의존성 주입. Controller에서, dmakerservice를 사용하겠다. 원래는 당연히 이런 꼴의 생성자 모습이 되어야 한다. 이러한 생성자의 실행이 ioc, 여기에 dmakeservice를 넣어주는것이 DI가 된다. 모든 빈을 다 가지고 있다가, DI를 컨트롤 해주는 것이 application context. 이 application context가 진행해주기 때문에, 별도의 생성자 생성이 필요없다. 2. AOP 일정 부분에서 일정 point에서 저장해주고, 문제가 생기면 exception을 발생시키고, 이러한 것들을 @Transactioanl을 통해서 수행된다.. 2023. 12. 30.
리팩토링 서비스가 확장되고 , 축소되고, 언어변경되고 , 모바일 지원요청받고 이렇게 여러가지 리팩토링이 필요하다 . 프로젝트의 변화의 복잡성을 감소 시켜준다 주로 품질 떨어진부분,복잡부분, 핵심서비스,향후 변경가능성 부분, 도전적인 부분에 적용하면 좋다. 1. REQUEST에서 PATHVARIABLE의 변수에는 FINAL 달아주기 2. service의 get method에, readonly = true로 하여 값이 변경되지 않게. 3. request앞에 @Nonnull 4. 중복기능 메소드 통합 즉, 코딩을 하다보니 이게 지금 접근이 가능하게 할까(private public) or final 들의 문제가 있었는데, 해당 문제들은 모두 코딩을 진행한 이후에 팀원의 합의 후, 변경하는 구조라는 것을 깨달았다. 2023. 12. 30.
테스트 테스트를 잘하는 방법 예전에는.. 테스트를 직접 하나씩 클릭하고 레코딩해서 팀이 테스트만 하였다 . (진짜 어려웠겠다는 생각을 했다.. 사실 테스트라는게 스스로 테스트 case를 생각하기 떄문에.. 어려운 부분이 많았다. 이런걸 하나하나씩 다 했다는게 진짜 대단하다 ) 다 짰는데 , 그다음에 기획이 바뀌고 코드가 다시 바뀌는 경우가 굉장히 많다. 코딩 -> 리팩터링 -> 테스트 -> 개선의 반복이다. CLASS, METHOD가 SRP를 잘 지켜야 한다. SRP? 단일 책임 원칙으로써, 하나의 객체는 하나의 책임(기능)을 담당해야한다. ENTITY에 사람정보 말고 갑자기 다른 기능이 있거나, 이래선 안된다. 이럴때가 TEST를 사용하기에 굉장히 유리한 상황이다! (또한, 그 크기가 너무 크지 않을때가 테스.. 2023. 12. 29.
예외 처리 이전에는 , 모든 exception에 대해서 try and catch를 진행했다. 모든 메소드를 거의 boolean으로 진행해서, try /catch or if절로 검사하여 return false방식으로 진행했다. ->해당 방식 문제. EXCEPTION을 별도로 생성해야 하는 문제가 발생한다. + 실패와 성공 각각을 DTO에 담아야 하는 , 복잡하고 이상한 형태의 구조가 동작된다. DTO에는 정보에 대한 것 뿐만 있어야하고, 예외등의 문제 관련하여는 존재해서는 안된다. -> 대부분을 VOID로 단순화하여, 예외를 생성하는 METHOD를 별개로 만든다. 코드의 간략화 , DTO의 간략화 예외만을 확인 예외를 던질지 말지를 실제 메소드에서 확인하고 넘어간다 (비지니스 VALIDATION) 이제 던져진 예외에.. 2023. 12. 29.