[꼼꼼한 개발자] 꼼코더

33. 코드로 배우는 스프링 웹 프로젝트 - [프레젠테이션(웹) 계층의 CRUD 구현] - Controller의 작성, BoardController의 분석, 목록에 대한 처리와 테스트 본문

Spring/코드로 배우는 스프링 웹 프로젝트

33. 코드로 배우는 스프링 웹 프로젝트 - [프레젠테이션(웹) 계층의 CRUD 구현] - Controller의 작성, BoardController의 분석, 목록에 대한 처리와 테스트

꼼코더 2023. 1. 9. 23:43
반응형
 

💡 Controller의 작성

스프링 MVC의 Controller는 하나의 클래스 내에 여러 메서드를 작성하고

@RequestMapping 등을 이용하여 URL을 분기하는 구조로 작성하기 때문에

하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성된다.

 

과거에는 이 단계에서 Tomcat(WAS)을 실행하고 웹 화면을 만들어

결과를 확인하는 방식의 코드를 작성해 왔었다.

 

하지만 시간이 오래 걸리고, 테스트를 자동화하기에 어려움이 많아

앞으로 할 예제에서는 WAS를 실행하지 않고 Controller를 테스트할 방법을 학습해 보자


🧐 BoardController의 분석

작성 전에는 ‘원하는 기능을 호출하는 방식에 대해 테이블로 정리 후 코드로 작성’하는 것 이 좋다.

테이블에서 From 항목은 해당 URL을 호출하기 위해서는 별도의 입력 화면이 필요하다는 것을 의미한다.

이에 대한 설계는 화면 구성 단계에서 진행할 수 있다.


👨🏻‍💻 BoardController의 작성

org.zerock.controller → BoardController 작성

작성내용은 URL 분석된 내용들을 반영하는 메서드를 설계한다.

BoardController는 @Controller 어노테이션을 추가하여 스프링 빈으로 인식할 수 있게 하고

@RequestMapping을 통해서 ‘/board’로 시작하는 모든 처리를 BoardController가 하도록 지정했다.

 

BoardController가 속한 org.zerock.controller 패키지는 servlet-context.xml에 기본으로 설정되어 있으므로 별도의 설정이 필요하지는 않다.(Java 설정 시 @ComponentScan을 이용)


👷🏻‍♂️ 목록에 대한 처리와 테스트

BoardController에서 전체 목록을 가져오는 처리를 먼저 작성한다.

BoardController는 BoardService 타입의 객체와 같이 연동해야 하므로 의존성에 대한 처리도 같이 진행한다.

BoardController는 BoardService에 대해서 의존적이므로

@AllArgsConstructor를 이용해 생성자를 만들고 자동으로 주입하도록 한다.

생성자를 만들지 않을 경우 @Setter(onMethod_={@Autowired)로 처리한다.

 

list()는 나중에 게시물의 목록을 전달해야 하므로 Model을 파리미터로 지정하고

이를 통해서 BoardServiceImpl 객체의 getList() 결과를 담아 전달한다(addAttribute).

 

BoardController 테스트는 스프링의 테스트 기능을 통해서 확인해 볼 수 있다.

 

👨🏻‍💻 BoardControllerTests 생성

src/tesst/java → org.zerock.controller 패키지 → BoardControllerTests 클래스 생성

테스트 코드는 기존과 다르게 진행될 예정이다 그 이유는

웹을 개발할 때 매번 URL을 테스트하기 위해 Tomcat(WAS)을 실행하는 불편한 단계를 생략하기 위함이다.

 

스프링의 테스트 기능을 활용하면 개발 당시에 Tomcat과 같은 WAS를 실행하지 않고 스프링과 웹 URL을 테스트할 수 있다.

 

WAS를 실행하지 않기 위해서는 약간의 추가적인 코드가 필요하지만

반복적으로 ‘서버를 실행’하고 ‘화면에 입력’하고, ‘오류를 수정’하는 단계를 줄여줄 수 있기 때문

Controller 테스트 시 고려해 볼 만한 방식이다.

👨🏻‍💻 BoardControllerTests 작성

테스트 클래스의 선언부에는 @WebAppConfiguration 어노테이션을 적용한다.

@WebAppConfiguration은 ServletContext를 이용하기 위해서 사용한다

스프링에서는 WebApplicationContext라는 존재를 이용하기 위해서는 필요한 어노테이션이다.

 

@Before 어노테이션이 적용된 setUp()에서는 Import 할 때 JUnit을 이용해야 한다.

@Before는 어노테이션이 적용된 메서드를 모든 테스트 시작 전 실행시킨다.

 

MockMvc는 말 그대로 ‘가짜 mvc’라고 생각하면 된다.

가짜로 URL과 파라미터 등을 브라우저에서 사용하는 것처럼 만들어서 Controller를 실행해 볼 수 있다.

 

testList()는 MockMvcRequestBuilders라는 존재를 이용해서 GET 방식의 호출을 한다.

이후에는 BoardController의 getList()에서 반환된 결과를 이용해서

Model에 어떤 데이터들이 담겨있는지 확인한다.


💁🏻‍♂️ 결과

Tomcat을 통해서 실행되는 방식이 아니므로

기존의 테스트 코드를 실행하는 것과 동일하게 실행해 준다.

testList()를 실행한 결과는 데이터베이스에 저장된 게시물들을 볼 수 있다.

 

 

🧹 최종 정리

@Controller 어노테이션을 추가하여 스프링 빈으로 인식

스프링의 테스트 기능을 활용하면 개발 당시에 Tomcat과 같은 WAS를 실행하지 않고 스프링과 웹 URL을 테스트할 수 있다.

WAS를 실행하지 않고 테스트 진행 시 반복적으로 ‘서버를 실행’하고 ‘화면에 입력’하고, ‘오류를 수정’하는 단계를 줄여줄 수 있다.

@WebAppConfiguration은 ServletContext를 이용하기 위해서 사용한다

@Before는 어노테이션이 적용된 메서드를 모든 테스트 시작 전 실행시킨다.

MockMvc는 말 그대로 ‘가짜 mvc’이다

가짜로 URL과 파라미터 등을 브라우저에서 사용하는 것처럼 만들어서 Controller를 실행한다

 

 

 
Comments