반응형

↓↓↓ 이전내용

2024.01.05 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (7) - JUnit TEST service 계층 test 예제

 

[REST API] Spring Boot로 REST API CRUD 간단 구현 (7) - JUnit TEST service 계층 test 예제

↓↓↓ 이전 내용 2023.12.30 - [Web Application/Backend] - [REST API] Spring Boot로 REST API CRUD 간단 구현 (6) - JUnit TEST 기본 설정 및 repository 계층 test 예제 [REST API] Spring Boot로 REST API CRUD 간단 구현 (6) - JUnit TEST

im-gonna.tistory.com

 

이전 내용에 이어서 이번에는 최상단 layer인 Controller의 test를 진행해보자.

 

main에 있는 controller class 이름에 ctrl+shift+t를 눌러서 test 클래스를 자동 생성해준다.

 

💡 Controller test class

 

import 되어있는 jupiter assertion은 제거한다. (이전에 설명했지만 기본 assertion 사용!)

 

  • 클래스 어노테이션 추가

외부 data와 직접 상호작용하는 계층이기 때문에 test class에 어노테이션을 추가해준다.

 

그리고 컨트롤러 클래스를 인자로 가져온다.

 

  • mockMvc 주입

 

web layer url test이기 때문에, 모의 MVC가 필요하다.

따라서 MockMvc 객체를 하나 선언하여 사용한다.

 

  • 필요한 객체 선언

controller 레이어는 service 레이어와 통신하기 때문에 모의 service를 만들어주어야 한다.

그리고 cloudvendor 인스턴스 2개를 각각 만들어 주고, 이들을 담을 리스트로 하나 선언해준다.

 

  • setUp 메서드

 cloudVendorOne 인스턴스와 cloudVendorTwo 인스턴스를 생성해주고, list에 담아준다.

 

 

  • getCloudVendorDetails()의 test 메서드

  • controller에 정의된 getCloudVendorDetails()의 로직을 보면, cloudVendorService의 getCloudVendor()를 호출한 결과를 반환한다.
  • 따라서 cloudVendorService의 getCloudVendor()에 cloudVendorId가 1로 전달하며, 이 메서드를 호출하면 cloudVendorOne을 return하여 성공적으로 보이도록 한다.
  • 그리고 mockMvc의 perform메서드를 통해 get 동작을 수행하도록 하고 url은 controller에서 지정한대로 cloudVendorId에 따라 달라지므로, /cloudvendor/1 로 가져오도록 한다.
  • andDo(print()): 이 메서드는 테스트 결과를 출력한다. 테스트가 실행될 때 컨트롤러가 반환하는 HTTP 응답 등의 정보를 콘솔에 출력하여 디버깅이나 테스트 결과 확인을 도와준다.
  • andExpect(status().isOk()): 이 메서드는 특정한 조건을 검증하는데, 여기서는 HTTP 응답의 상태 코드가 "200 OK"인지 확인한다. 만약 상태 코드가 200이 아니면 테스트는 실패하는 것이다.
  • 여기까지하면, perform get에서 빨간 줄이 쳐질 것이다. 예외처리가 필요하다. 메서드에 throws Exception을 추가해주자.

getCloudVendorDetails test 결과

 

테스트 결과 성공이다.

getCloudVendorDetails()의 test를 위해 모의(mock) http 서블릿 요청이 제대로 구축되는 것을 확인할 수 있다.

(이는 마치 레포지토리 레이어에서 내장된 데이터베이스 h2를 사용하는 것과 유사한 상황이다)

파라미터와 헤더는 아무것도 필요로 하지 않았다.

 

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"application/json"]
     Content type = application/json
             Body = {"data":{"vendorId":"1","vendorName":"Amazon","vendorAddress":"USA","vendorPhoneNumber":"xxxxx"},"httpStatus":"OK","message":"Requested Vendor Details are given here"}
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

 

그 아래 더 내려서 response 부분을 보면, status는 200, 에러 사항 없음, body data에 controller에서 반환하는 CloudVendorOne에 대한 data가 담겨져 있는 것을 확인할 수 있다.

 

 

  • getAllCloudVendorDetails()의 test 메서드

  • 앞의 get메서드와 로직은 유사하나, service 메서드를 getAll로 수정해주고, 가져오는 단위가 list이기 때문에, 초기에 설정해주었던 cloudVendorList를 return하도록 한다.
  • 모든 cloudVendor를 가져올 때에는 기본 url을 사용하기 때문에, /cloudvendor로 mapping되도록 한다. 

getAllCloudVendorDetails test 결과

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"application/json"]
     Content type = application/json
             Body = [{"vendorId":"1","vendorName":"Amazon","vendorAddress":"USA","vendorPhoneNumber":"xxxxx"},{"vendorId":"2","vendorName":"GCP","vendorAddress":"UK","vendorPhoneNumber":"yyyyy"}]
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

 

body를 보면 one, tow 모두 값을 가져오는 것을 확인할 수 있다.

 

 

  • deleteCloudVendorDetails()의 test 메서드

  • controller의 delete 메서드 로직을 보면, service의 delete메서드를 호출하고, 이 안에서는 Success 메시지를 반환하도록 되어있다.
  • 따라서 cloudvendorId가 1인 cloudvendor를 delete하도록 service 메서드가 호출되면, Success를 return하도록 하여, service의 delete 메서드 호출을 성공적으로 보이게 한다.
  • 그리고 mockMvc의 perform을 통해 delete mapping시 url은 /cloudvendor/1에 매핑되도록 한다.

deleteCloudVendorDetails test 결과

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"text/plain;charset=UTF-8", Content-Length:"33"]
     Content type = text/plain;charset=UTF-8
             Body = Cloud Vendor Deleted Successfully
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

 

response의 body를 보면 controller의 해당 메서드에서 반환하는 값인 메시지를 반환하는 것을 확인할 수 있다.

 

 

  • createCloudVendorDetails()의 test 메서드

 

  • controller에서 create메서드 로직을 살펴보면, cloudVendorService의 create메서드를 호출한다. 그 메서드 안에서는 success를 return한다.
  • 따라서 create메서드가 호출되면 Sucess를 return하도록 한다.
  • perform의 post mapping 시 /cloudvendor url과 mapping되도록 한다.
  • 그런데, 내용으로 전달되는 data를 json형식으로 전달하여야 하기 때문에, contentType을 json으로 지정해준다.
  • 그런데, cloudvendor는 entity이기 때문에, json형식으로 바꾸어주기 위해 위 코드를 작성해준다.
  • json 형식의 cloudvendor를 requestJson에 저장해주고, requestJson을 content에 넣는다.

createCloudVendorDetails test 결과

 

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"text/plain;charset=UTF-8", Content-Length:"33"]
     Content type = text/plain;charset=UTF-8
             Body = Cloud Vendor Created Successfully
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

 

response의 body를 보면 controller의 해당 메서드에서 반환하는 값인 메시지를 반환하는 것을 확인할 수 있다.

 

 

  • updateCloudVendorDetails()의 test 메서드

  • 앞의 create 메서드와 로직이 유사하기 때문에, service 메서드의 create를 update로 변경하고, perform메서드는 post를 put으로 변경한다.

updateCloudVendorDetails test 결과

 

MockHttpServletResponse:
           Status = 200
    Error message = null
          Headers = [Content-Type:"text/plain;charset=UTF-8", Content-Length:"33"]
     Content type = text/plain;charset=UTF-8
             Body = Cloud Vendor Updated Successfully
    Forwarded URL = null
   Redirected URL = null
          Cookies = []

 

역시 response의 body에는 controller의 해당 메서드에서 반환하는 값인 메시지를 담고 있다.

 

모든 unit test를 마쳤으므로, 전체 test class의 test coverage를 확인해보자.

 

controller의 test coverage 결과

test coverage가 100% 인것을 확인하였다.

 

summery

 

 

↓↓↓ 다음 내용

2024.01.25 - [Web Application/Backend] - [REST API] Spring Boot로 REST API 프로젝트 (9) - Swagger로 api document 생성하기

 

[REST API] Spring Boot로 REST API 프로젝트 (9) - Swagger로 api document 생성하기

↓↓↓이전내용 2024.01.10 - [Web Application/Backend] - [REST API] Spring Boot로 REST API 프로젝트 (8) - JUnit TEST controller 계층 test 예제 [REST API] Spring Boot로 REST API 프로젝트 (8) - JUnit TEST controller 계층 test 예제 ↓

im-gonna.tistory.com

반응형
반응형

우리가 주소창에 주소를 입력하고 해당 페이지로 이동하여 화면에 보여지는 과정은 어떻게 이루어질까?

  • 주소창에 url을 입력하고 enter를 누르면, 서버에 요청이 전송된다.
  • 해당 페이지에 존재하는 여러 자원들 (text, image 등등)이 보내진다.
  • 이제 브라우저는 해당 자원이 담긴 html과 스타일이 담긴 css를 W3C 명세에 따라 해석할 것이다.
    => 이 역할을 하는 것이 "렌더링 엔진"
  • 렌더링 엔진은 우선 html 파싱 과정을 시작한다. html 파서가 문서에 존재하는 어휘와 구문을 분석하면서 DOM 트리를 구축한다.
  • 다음엔 css 파싱 과정을 시작한다. css 파서가 모든 css 정보를 스타일 구조체로 생성한다.
  • 이 2가지를 연결시켜 렌터 트리를 만든다.
    => 렌더링 엔진을 통해 (DOM 트리 + 스타일 구조체 = 렌더 트리)를 만든다!!
  • 즉 렌더 트리를 통해 문서가 시각적 요소를 포함한 형태로 구성된 상태가 된다.
  • 화면에 배치를 시작하고, UI 백엔드가 노드를 돌며 형상을 그린다.
  • 이때 빠른 브라우저 화면 표시를 위해 '배치와 그리는 과정'은 페이지 정보를 모두 받고 한꺼번에 진행되지 않는다.
  • 자원을 전송 받으면, 기다리는 동시에 일부분 먼저 진행하고 화면에 표시한다.
    => 우리가 웹 페이지에 접속할 때 한꺼번에 뜨지 않고 점점 화면에 나오는 것이 이 때문이다!!

 

***아래는 각 단계에서의 세부 동작에 관한 내용이다

브라우저 주요 기능


브라우저는 html과 css 명세에 따라 html 파일을 해석해서 표시한다.

이 "명세"는 웹 표준화 기구인 W3C(world wide web consortium)에서 정해진다.

예전 브라우저들은 일부만 명세에 따라 구현하고 독자적 방법으로 확장했음 -> 결국 심각한 호환성 문제가 발생하고, 요즘은 대부분 모두 표준 명세를 따름

 

 

브라우저가 가진 인터페이스는 보통 비슷비슷한 요소들이 존재한다.

** 브라우저가 가진 인터페이스는 아래와 같은 것들

시간이 지나면서, 사용자에게 필요한 서비스들로 서로 모방하며 갖춰지게 된 것

 

  • URI 입력하는 주소 표시 줄
  • 이전 버튼, 다음 버튼
  • 북마크(즐겨찾기)
  • 새로 고침 버튼
  • 홈버튼...등등

 

 

브라우저 기본 구조


 

  • 사용자 인터페이스
    주소 표시줄, 이전/다음 버튼, 북마크 등 사용자가 활용하는 서비스들 (요청한 페이지를 보여주는 창을 제외한 나머지 부분)
  • 브라우저 엔진
    사용자 인터페이스와 렌더링 엔진 사이의 동작 제어
  • 렌더링 엔진
    요청한 콘텐츠 표시 (html 요청이 들어오면? -> html, css 파싱해서 화면에 표시)
  • 통신
    http 요청과 같은 네트워크 호출에 사용 (플랫폼의 독립적인 인터페이스로 구성되어 있음)
  • UI 백엔드
    플랫폼에서 명시하지 않은 일반적 인터페이스. 콤보 박스 창 같은 기본적 장치를 그림
  • 자바스트립트 해석기
    자바스트립트 코드를 해석하고 실행
  • 자료 저장소
    쿠키 등 모든 종류의 자원을 하드 디스크에 저장하는 계층

 

렌더링이란?


렌더링 엔진은 요청받은 내용을 브라우저 화면에 표시해준다.

기본적으로 html, xml 문서와 이미지를 표시할 수 있다.

추가로 플러그인이나 브라우저 확장 기능으로 pdf 등 다른 유형도 표시가 가능하다.

(확장이 필요한 유형은 바로 뜨지 않고 팝업으로 확장 여부를 묻는 것을 볼 수 있다)

 

렌더링 엔진 종류

  • 크롬, 사파리 : 웹킷(Webkit) 엔진 사용
  • 파이어폭스 : 게코(Gecko) 엔진 사용

웹킷(Webkit) : 최초 리눅스 플랫폼에 동작하기 위한 오픈소스 엔진

 

렌더링 동작 과정

DOM : Document Object Model (문서 객체 모델)
DOM은 웹 브라우저가 html 페이지를 인식하는 방식

 

 

파싱


문서 파싱은, 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것이다.

문서를 가지고 어휘분석과 구문 분석 과정을 거쳐 파싱 트리를 구축한다.

 

 

 

 

 

*** Gyoogle.com 글을 참고하였습니다.
반응형

'Web Application' 카테고리의 다른 글

REST API  (0) 2023.12.29
HTTP status code (HTTP 상태 코드)  (0) 2023.12.28
HTTP Request Methods  (0) 2023.12.23
쿠키(cookie)와 세션(session)의 차이  (1) 2023.12.22
[Node.js] Node.js와 Javascript의 개념  (0) 2023.09.13

+ Recent posts