답변:
JSP를 테스트하는 좋은 방법은 없다고 생각합니다. 주로 단위 테스트가 개발의 초점이되기 전에 개발 되었기 때문입니다.
Robert Martin은 몇 년 전 JSP 컴파일러 해킹에 대한 기사를 작성하여 컨테이너를 기반으로하지 않는 단위 테스트를 지시 할 수 있습니다. 그의 아이디어는 좋았지 만 다음 TomCat 메이저 릴리스에서는 깨졌습니다. 너무 많은 마법이 진행되고 있습니다.
"코드를 추가하지 않고 테스트 할 필요가 없습니다"라는 아이디어에 동의하지 않습니다. 분명히 JSP에 코드를 넣지 말아야합니다. 그럼에도 불구하고 복잡한 UI는 종종 유리하게 단위 테스트가 가능한 디스플레이 로직을 갖습니다.
이 예제를 고려하십시오.
<c:choose>
<c:when test="${mydto.showAdminMenu}">
The admin menu....
</c:when>
<c:otherwise>
Something completely different
</c:otherwise>
</c:choose>
이 코드는 이미 잘 정의되어 있습니다. 관리 메뉴를 표시할지 여부를 결정하는 논리가 표시되지 않습니다. 그럼에도 불구하고 JSP를 단위 테스트하는 쉬운 방법이 있다면 원하는 동작이 실제로 나타나는지 보여주는 테스트를 작성할 수 있으며 관리자 메뉴가 실수로 표시되어야하는 페이지가 변경되지 않도록 보호 할 수 있습니다. 하지마
.jsp 파일을 .java 파일로 컴파일하는 프로그램 (사용중인 응용 프로그램 서버에서 사용)이 있습니다. 예를 들어, sun / oracle 버전 jspc 입니다.
.jsp 변환으로 생성되는 .java가 있으면 (이를 빌드 프로세스의 일부로 사용하는 것도 고려할 수도 있습니다-첫 번째 적중시 성능 향상을 위해 jsp를 사전 컴파일) 테스트를 실행할 수 있습니다. 요청을 조롱하고 응답을 확인하여 기대하는 것입니다.
(예를 들어 편집 :)
이를위한 주요 방법은 _jspService(HttpServletRequest, HttpServletResponse)방법입니다.
사소한 hello world jsp :
<html>
<head>
<title>Hello world</title>
</head>
<body>
<h1>Hello world</h1>
Today is: <%= new java.util.Date().toString() %>
</body>
</html>
( 'webapp'라는 디렉토리와 'out'디렉토리에있는 test.jsp) 명령으로 컴파일 할 때 jspc -v -d out -compile -uriroot webapp/ test.jsp파일을 out 디렉토리에 배치합니다 test_jsp.java. 이 파일에는 다른 구성 설정과 함께 다음과 같은 내용이 포함되어 있습니다.
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
PageContext pageContext = null;
HttpSession session = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;
PageContext _jspx_page_context = null;
try {
response.setContentType("text/html");
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
_jspx_page_context = pageContext;
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
out.write("<html>\n\t<head>\n\t\t<title>Hello world</title>\n\t</head>\n\t<body>\n\t
\t<h1>Hello world</h1>\n\t\tToday is: ");
out.print( new java.util.Date().toString() );
out.write("\n\t</body>\n</html>\n\n");
} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
try { out.clearBuffer(); } catch (java.io.IOException e) {}
if (_jspx_page_context != null) _jspx_page_context.handlePageException(t);
}
} finally {
_jspxFactory.releasePageContext(_jspx_page_context);
}
}
}
이 시점에서 JspWriter가 쓰기 또는 인쇄로 호출되고 호출 내용이 예상 한 것인지 확인합니다.
이상적으로 이상적인 세계에서는 jsp 내에 로직이 없어야합니다. 이러한 로직은 컨트롤러 또는 다른 기술로 테스트 된 taglib에 있습니다.
HTTPUnit | HTTP와 같은 HTTP 단위 테스트 프레임 워크 사용을 고려할 수도 있습니다. http://httpunit.sourceforge.net/ .
또 다른 중요한 점은 응용 프로그램의 우려를 잘 구분하는 것입니다.
예를 들어 TDD (http://en.wikipedia.org/wiki/Test-driven_development) 와 같은 기술을 사용하여 테스트 가능성을위한 유형을 디자인합니다.
JSP 내에서 소비되는 유형은 특정 단위 테스트에서 테스트됩니다. 이것이 가능하지 않은 경우, 사용자-> 브라우저 상호 작용을 시뮬레이션해야합니다 (HTTPUnit 또는 유사한 도구).