servlet에 대한 테스트 용례 쓰기 - jsp 요청 포함
구체적인 용도는 다음과 같다.
As a testing tool, HttpUnit is primarily designed for "black-box"testing of web sites. In many cases that may be all you need; however, if you are developing complex servlets, you may wish to test smaller pieces of your code. Sometimes you can isolate them into simple tests using only JUnit. In other cases, you will want to test in a servlet environment. At this point you have two basic approaches available. You can test in a real servlet container, using a tool such as Apache Cactus, which has you deploy your tests into the container along with your servlets. Or you can use a simulated servlet container. ServletUnit takes the latter approach.
Getting Started with ServletUnit
To test a servlet in ServletUnit, you first instantiate aServletRunner(the simulated container), and register your servlets:
ServletRunner sr = new ServletRunner();
sr.registerServlet( "myServlet", StatefulServlet.class.getName() );
Note that for complex tests, you can register multiple servlets in a singleServletRunneror initialize theServletRunnerwith the name of a web.xml file from which to read an entire application full of servlets. You are now ready to begin. You need aServletUnitClient, which performs much the same function as HttpUnit'sWebConversation- in fact, they both extend the base classWebClient, so you can use it the same way, except of course thatServletUnitClientignores the host portion of URLs in requests passed to it and goes directly to itsServletRunner. This means that you can invoke the servlet and handle its response in the same way you have been accustomed to in HttpUnit:
ServletUnitClient sc = sr.newClient();
WebRequest request = new PostMethodWebRequest( "http://test.meterware.com/myServlet" );
request.setParameter( "color", "red" );
WebResponse response = sc.getResponse( request );
assertNotNull( "No response received", response );
assertEquals( "content type", "text/plain", response.getContentType() );
assertEquals( "requested resource", "You selected red", response.getText() );
Testing Servlet Internals
The above approach is still black-box testing. To really take advantage of the power of ServletUnit, you can handle your request in steps. To do this, instead of asking the client for the final response, you ask it for an invocation context:
ServletUnitClient sc = sr.newClient();
WebRequest request = new PostMethodWebRequest( "http://test.meterware.com/myServlet" );
request.setParameter( "color", "red" );
InvocationContext ic = sc.newInvocation( request );
This invocation context provides access to the selected servlet, which has been initialized for you with the appropriate session information, as well as the request and response objects which the servlet will process. Now you can call methods on the servlet, on the servlet session, or on the request and response objects. For example, given the following servlet definition:
public class StatefulServlet extends HttpServlet { protected void doPost( HttpServletRequest req, HttpServletResponse resp ) throws ServletException,IOException {
resp.setContentType( "text/plain" );
writeSelectMessage( req.getParameter( "color" ), resp.getWriter() );
setColor( req, req.getParameter( "color" ) );
} void writeSelectMessage( String color, PrintWriter pw ) throws IOException {
pw.print( "You selected " + color );
pw.close();
} void setColor( HttpServletRequest req, String color ) throws ServletException {
req.getSession().setAttribute( "color", color );
}
}
you might want to test the individual methods one at a time. The following code obtains the servlet and casts it to get access to its package-level methods (the tests should be in the same package as the servlet to do this). It then invokes the setColor method to ensure that it is creating and updating the session correctly.
StatefulServlet ss = (StatefulServlet) ic.getServlet();
assertNull( "A session already exists", ic.getRequest().getSession( false ) );
ss.setColor( ic.getRequest(), "blue" );
assertNotNull( "Session was not created", ic.getRequest().getSession( false ) );
assertEquals( "Color in session", "blue", ic.getRequest().getSession().getAttribute( "color" ) );
You can test the response from the servlet as well, if you invoke the code which creates it:
StatefulServlet ss = (StatefulServlet) ic.getServlet();
ic.getResponse().setContentType( "text/plain" );
ss.writeSelectMessage( "blue", ic.getResponse().getWriter() );
WebResponse response = ic.getServletResponse();
assertEquals( "requested resource", "You selected blue", response.getText() );
assertEquals( "Returned cookie count", 1, response.getNewCookieNames().length );
Note first that you must do all of the processing that theservicemethod would have done if you take this approach. You may either call theservicemethod itself, or a combination of other calls that will prepare the response in the fashion you wish to test. Not also that the response returned fromgetServletResponseis the actual one returned by the servlet, without any processing by the client. For example, if the request contains a bad status or a forward request, the client might do some additional processing, which is not done at this time. Of course, since the response extendsWebResponse, all of the normal HTML parsing methods are available to examine it.
Maintaining State Across Multiple Responses
If you are usingInvocationContextto access servlet internals, you are usually not completing the request cycle; as a result, the client will not process any cookies and state will not be maintained across requests. In many cases, this is OK. But if you are writing a test which depends on the maintenance of state across servlet invocations, you will want to reinvolve theServletUnitClient, giving it a chance to process the response, including updating its own list of cookies:
WebResponse response sc.getResponse( ic ); // pass the already processed InvocationContext
response = sc.getResponse( "http://test.meterware.com/ReadColorFromSession" );
assertNotNull( "No response received", response );
assertEquals( "content type", "text/plain", response.getContentType() );
assertEquals( "requested resource", "You posted blue", response.getText() );
assertEquals( "Returned cookie count", 0, response.getNewCookieNames().length );
This allows any subsequent request through the same client object to take advantage of the session state established by the just completed request, just as is possible with HttpUnit.
Testing Security
If you are using a web.xml file to define your servlets, you can also test protected resources. ServletUnit supports both Basic and Form authentication, and handles them just as HttpUnit does. For Basic authentication, you must call setAuthorization passing a username and password, while Form authentication is handled just like any other form. Since ServletUnit does not maintain a database of users, it will accept any user/password combination as valid, and treat the password as a comma-separated list of role names. http://httpunit.sourceforge.net/doc/servletunit-intro.html
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
5분 안에 JSP 배우기Java 생태계는 지난 20년 동안 많이 발전했으며 이는 시장에서 변함없이 인기를 얻고 있음으로 알 수 있습니다. 글쎄, 이것은 다른 프로그래밍 언어 중 하나에 대한 탄탄한 배경이 있거나 새로운 개발자이지만 시간이 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.