Spring MVC

springmvc.egloos.com


포토로그


2012/01/30 22:38

이클립스에서 SpringMVC 테스트(JUnit) 환경 구축하기 개발환경 구축

이클립스는 정말 대단한 프로그램이다. 만약에 돈을 주고 사야 했더라도 반드시 구매했을 것이다. 이런 엄청난 소프트웨어를 오픈소스로 공개한 이클립스 재단 덕분에 전세계 자바프로그래머들은 편하고 쉽게 자바 프로그램을 개발할 수 있게 되었다. 하지만 오픈소스들이 대개 그렇듯 각자의 영역에서 독자적인 방식으로 개발된지라 이런 시스템을 하나로 통합하는 과정은 어느 정도 유저의 손에 맡겨져 있는 게 사실이다. 상업 소프트웨어에서는 상상도 할 수 없는 일이지만 이런 대단한 시스템을 사용하려면 어느 정도 감수해야할 부분이다.

오늘은 이클립스에서 새로작성 > SpringSource Tool Suite > Spring Template Project > Spring MVC 로 작성한 환경을 기반으로 JUnit을 활용한 테스트 환경구축에 대해 글을 써보겠다. 스프링을 이용하면서 JUnit을 활용하지 않겠다는 것은 맛있는 진수성찬을 맨손으로 먹는 것이나 다름없다. 우리는 동방예의지국의 후손들이기 때문에 숫가락, 젓가락, 포크, 나이프 가리지 않고 자유자재로 사용하여 프로그래밍을 작성해야 한다.

만약에 Spring MVC로 아직 이클립스 프로젝트를 작성하지 않았다면 이클립스 + 톰캣 + 스프링 MVC + maven 개발환경 구축을 읽어나가며 환경 조성을 먼저 해주어야 한다.


스프링을 통해 개발하면서 테스트 환경을 구축하는 것은 매우 중요한데 이클립스는 사용자가 정확히 어떻게 돌아가는지는 몰라도 어쨌든 훌륭한 테스트 환경을 구축해준다. 문제는 이클립스가 제대로 테스트 환경을 구축해주지 못한다면 이클립스의 내부가 어찌 돌아가는지도 모르는 판에 어떻게 손을 데야 제대로된 테스트 환경을 구축할 수 있는지 알 수가 없다는 것이다!

이 사진은 앞으로 우리가 갖추게될 완벽한 테스트 환경을 보여준다. 초기 설정을 거의 건들지 않고 SpringMVC에서 막 바로 튀어나온 따끈따끈한 클래스들과 root-context.xml 파일을 별다른 무리 없이 읽어오는 것이 가능하다. appServlet폴더에 있는 servlet-context.xml도 불러오면 좋겠지만 그 부분은 서버 환경에서 테스트하는 것이 올바르며 현재 모델설계에는 root-context.xml을 올바르게 읽어오는 것이 급선무다.

먼저 이런 환경을 구축하려면 이클립스가 어떻게 테스트 환경을 구축하는지 정확히 알아야 한다. (여기서 이클립스가 구축하는 테스트 환경이란 따로 브라우져나 외부 테스트 환경에서 알아보는게 아니라 바로 이클립스 내부의 실행 버튼만으로 작성한 클래스를 평가하는 것을 말한다.) 이클립스는 정확히 말해 현재 작성 중인 프로젝트를 이용해 실행(테스트) 하지 않고 프로젝트에서 설정한 경로를 통해 따로 자원들을 불러들인 뒤 이를 이클립스 스스로 재조립해서 실행한다.

그러므로 이클립스의 실행은 당신의 로컬경로의 프로젝트와 완벽하게 무관한 것이다. 제대로된 테스트 환경이 갖추어지지 않았다면 이클립스의 프로젝트 설정을 봐야되지 애꿎은 로컬 경로의 소스들을 이리 옮기고 저리 옮기고 하는 짓은 아무 짝에도 쓸모없다. 

예를 하나 들어보자. 우리는 이전 개발환경 구축을 통해 이클립스가 톰캣을 이용해 현재 작성 중인 SpringMVC 프로젝트를 (서버환경에서) 실행할 수 있다는 것을 알 수 있었다. 근데 이전에 한번이라도 톰캣 서버를 구동해본 경험이 있는 사람은 상식적으로 이해할 수 없는 환경이었을 거다. 필자도 그러했다. 왜냐하면 현재 작성 중인 프로젝트는 일반적인 톰캣의 구동환경에서는 절대로 돌아갈 수 없는 폴더구성이었기 때문이다. 

톰캣은 절대로 target\classes와 같은 경로에서 소스를 불러오지 않는다. 톰캣은 오로지 WEB-INF/classes에서만 소스를 불러온다. 그리고 톰캣은 자동으로 C:\Users\사용자\.m2\repository\commons-httpclient\commons-httpclient\3.1 같은 폴더에서 필요한 라이브러리들을 소환하는 기능도 없다. 오로지 WEB-INF/lib 폴더에서만 필요한 jar파일들을 읽어들일 수 있다.

그렇다면 이클립스는 도대체 무슨 마법을 부렸길래 이런 복잡한 폴더구성에도 안전하게 서버를 구동시킬 수 있었던 것일까? 그 답은 먼저 말했듯이 이클립스가 자원을 스스로 재조립해 서버를 실행하는 똑똑한 IDE툴이었기 때문에 가능했던 것이다. 만약에 톰캣을 이용해 해당 프로젝트를 Run on Server로 구동한다면 이클립스는 해당 프로젝트의 Deployment Assembly의 경로를 이용해 필요한 자원을 재조립한다.

[프로젝트 - 특성 - Deployment Assembly의 구성화면]

먼저 소스와 Deploy Path를 보도록 하자. 이클립스는 소스, 즉 현재 작성된 프로젝트를 기준으로 해당 위치에 있는 소스들을 이클립스가 Deploy Path에 있는 경로로 재조립하여 실행한다. Deploy Path를 보면 누구나 알 수 있듯이 톰캣이 이해할 수 있는 서버 폴더구성이다. 그렇다면 Deploy Path는 어디로 가는 걸까? 그 답은 아래 사진에 있다.


현재 위치는 이클립스가 스스로 재조립한 폴더이다. 기존에 톰캣 프로젝트를 많이 만들어본 사람이라면 한눈에 이해할 수 있을 만큼 심플한 톰캣 프로젝트라는 것을 알 수 있는데 이 폴더가 위치한 경로는 다음과 같다.

[CATALINA_HOME]\webapps\.metadata\.plugins\org.eclipse.wst.server.core\tmp1\wtpwebapps

여기서 CATALINA_HOME은 환경변수에 등록된 톰캣의 경로를 말하는 것이고 (물론 톰캣 폴더의 위치는 이클립스에서 설정한 것이 우선이다.) 경로 가장 뒷 부분인 tmp1은 tmp0 일수도 있고 tmp2 일수도 있다. 서로 중복되지 않도록 이클립스에서 지정한 임시보관 폴더의 명명일 뿐이다.

이런 환경이라면 우리는 앞으로 Custom하여 서버환경을 구성하는데 Deployment Assembly가 매우 중요한 역할을 한다는 것을 알 수 있게 됬다. 그런데 문제는 여기서 끝이 아니다. 서버환경을 구성하는 방법에 대해서는 알게 되었지만 매번 프로젝트를 서버환경에서만 테스트 할거라면 JUnit이 무슨 소용이냔 말이다. 우리가 진정 원했던 테스트 환경은 아래와 같은 것이 아니었나?

위와 같은 테스트 환경을 갖추려면 우리는 root-context파일을 원하는 대로 읽어올 수 있어야 한다. 우리가 기존에 책을 통해 알기로는 이런 테스트 방식을 갖추려면 root-context.xml을  bin폴더의 가장 상단에 위치시켜두었어야 했는데 이제는 bin폴더도 없고 작성된 소스들이 어디서 컴파일되 어디로 나가는지도 모르겠다. 도대체 어떻게 하면 좋을까?

[프로젝트 - 특성 - Java 빌드 경로의 구성화면]

해답은 바로 "Java 빌드 경로"에 있다. 여기의 빌드 경로는 Deployment Assembly와 다르게 이클립스가 binary파일 상태에서 실행가능하도록 폴더자체를 동기화 시켜주는 역할을 한다. 위의 빨간 박스안에 경로를 보면 root-context.xml 파일이 위치한 경로라는 것을 알 수 있을 것이다. 우리는 위의 경로를 이클립스가 읽어들이는 빌드경로에 함께 동기화 시켜줌으로서 맨 처럼 보여줬던 JUnit 테스트 환경이 구축될 수 있도록 도와줄 것이다.


다음과 같은 순서로 root-context.xml파일을 설정해보자. Java 빌드 경로에서 폴더추가를 누른 뒤 src/main/webapp/spring폴더를 선택한다. 그리고 따로 선택된 폴더를 편집하여 출력폴더를 target/classes로 설정해주도록 하자. 그리고 확인을 누르면 이클립스가 알아서 spring폴더에 있는 파일들을 target/classes 동기화 시켜줄 것이다. 이제 우리는 spring폴더의 xml파일만 수정해도 똑같이 target/classes에도 적용된다는 사실을 알 수 있을 것이다.

여기서 target폴더는 우리가 프로젝트를 모두 완성한 뒤, 작성한 class 파일들을 빠르게 jar로 배포할 수 있도록 maven에서 만든 폴더이다. 이를 사용자가 원하는대로 변경할 수도 있지만 가급적 target의 classes를 이용하도록 하자. 완성된 프로젝트를 jar로 관리하는 것은 버전관리에도 유익할 뿐더러 괜히 설정을 바꾸어 어지럽힐 이유도 없다.

이제 모두 완성했으면 이클립스의 JUnit을 이용해 root-context를 올바르게 읽어들이고 있는지 확인해보자.

제대로 따라왔다면 위와 같이 XML문서도 제대로 읽어들이고 테스트에도 성공할 수 있을 것이다.

핑백

  • Spring MVC by happenstantial : 스프링 4주차의 헛소리 - (3) MyBatis + 커넥션풀 + 트랜잭션 2장 2012-02-20 20:05:47 #

    ... 컨텍스트 XML파일이 target/classes폴더에 들어가야 하는데 이에 대한 자세한 설명은 다음의 포스트를 읽으면 감이 올 것이다. 이클립스에서 SpringMVC 테스트(JUnit) 환경 구축하기 테스트 결과는 성공이다. 이제 스프링과 MyBatis가 성공적으로 연결되었고 마지막으로 스프링 트랜잭션만 설정하면 끝이다. &lt ... more

  • 그런지 Ltd. : springMVC 2013-07-25 18:37:05 #

    ... 3장 - http://springmvc.egloos.com/429779이클립스에서 SpringMVC 테스트(JUnit) 환경 구축하기 - http://springmvc.egloos.com/438345STS의 Spring Template Project를 이용한 간단한 Spring MVC 웹 프로젝트 http://www.mungchu ... more

덧글

  • 잘봤습니다. 2017/02/27 20:48 # 삭제 답글

    잘 보고 갑니다.
댓글 입력 영역