Testing Web-based applications Typically, a multi-layered architecture is used. Three primary layers, typically on different hosts: –Client: –often uses.

Slides:



Advertisements
Similar presentations
Chapter 6 Server-side Programming: Java Servlets
Advertisements

Introduction to Servlets Based on: Hall, Brown, Core Servlets and JavaServer Pages.
An architecture for webb applications, J2EE
Object-Oriented Enterprise Application Development Tomcat 3.2 Configuration Last Updated: 03/30/2001.
Servlets and a little bit of Web Services Russell Beale.
WEB1P servintro1 Introduction to servlets and JSP Dr Jim Briggs.
An introduction to Java Servlet Programming
Liang, Introduction to Java Programming, Sixth Edition, (c) 2005 Pearson Education, Inc. All rights reserved Chapter 34 Servlets.
Outline IS400: Development of Business Applications on the Internet Fall 2004 Instructor: Dr. Boris Jukic Server Side Web Technologies: Part 2.
1 Java Server Pages Can web pages be created specially for each user? What part does Java play?
1 The World Wide Web. 2  Web Fundamentals  Pages are defined by the Hypertext Markup Language (HTML) and contain text, graphics, audio, video and software.
Session-01. What is a Servlet? Servlet can be described in many ways, depending on the context: 1.Servlet is a technology i.e. used to create web application.
Web Applications Basics. Introduction to Web Web features Clent/Server HTTP HyperText Markup Language URL addresses Web server - a computer program that.
ECE356 – Database Systems Lab 1 – Building a Web Project with NetBeans Tiuley Alguindigue Lab Instructor – University of Waterloo, E & CE Dept. Fall 2013.
SE-2840 Dr. Mark L. Hornick1 Java Servlet-based web apps Servlet Architecture.
Introduction to Java web programming Dr Jim Briggs JWP intro1.
Gayle J Yaverbaum, PhD Professor of Information Systems Penn State Harrisburg.
Intro to Servlets Lec 26. Web-Based Enterprise Applications in Java Figure shows a simplified view of one application and its layers.
Christopher M. Pascucci Basic Structural Concepts of.NET Browser – Server Interaction.
UNIT-V The MVC architecture and Struts Framework.
Java Server Pages B.Ramamurthy. Topics for Discussion 8/20/20152 Inheritance and Polymorphism Develop an example for inheritance and polymorphism JSP.
DAT602 Database Application Development Lecture 15 Java Server Pages Part 1.
M. Taimoor Khan * Java Server Pages (JSP) is a server-side programming technology that enables the creation of dynamic,
FALL 2005CSI 4118 – UNIVERSITY OF OTTAWA1 Part 4 Web technologies: HTTP, CGI, PHP,Java applets)
Simple Web Services. Internet Basics The Internet is based on a communication protocol named TCP (Transmission Control Protocol) TCP allows programs running.
Comp2513 Forms and CGI Server Applications Daniel L. Silver, Ph.D.
Simple Web Services. Internet Basics The Internet is based on a communication protocol named TCP (Transmission Control Protocol) TCP allows programs running.
Java Omar Rana University of South Asia. Course Overview JAVA  C/C++ and JAVA Comparison  OOP in JAVA  Exception Handling  Streams  Graphics User.
Using JavaBeans and Custom Tags in JSP Lesson 3B / Slide 1 of 37 J2EE Web Components Pre-assessment Questions 1.The _____________ attribute of a JSP page.
Chapter 17 - Deploying Java Applications on the Web1 Chapter 17 Deploying Java Applications on the Web.
Objectives Java Servlet Web Components
JSP Java Server Pages Softsmith Infotech.
Li Tak Sing COMPS311F. Static attributes in Servlets Since Servlets are also Java classes, you can also use static attributes to store values that can.
Chapter 7 Java Server Pages. Objectives Explain how the separation of concerns principle applies to JSP Describe the operation and life-cycle of a JSP.
COMP 321 Week 7. Overview HTML and HTTP Basics Dynamic Web Content ServletsMVC Tomcat in Eclipse Demonstration Lab 7-1 Introduction.
Lecturer: Prof. Piero Fraternali, Teaching Assistant: Alessandro Bozzon, Advanced Web Technologies: Struts–
JAVA SERVER PAGES CREATING DYNAMIC WEB PAGES USING JAVA James Faeldon CS 119 Enterprise Systems Programming.
Chapter 3 Servlet Basics. 1.Recall the Servlet Role 2.Basic Servlet Structure 3.A simple servlet that generates plain text 4.A servlet that generates.
Java Servlets & Java Server Pages Lecture July 2013.
Chapter 6 Server-side Programming: Java Servlets
1 MSCS 237 Overview of web technologies (A specific type of distributed systems)
® IBM Software Group © 2007 IBM Corporation Best Practices for Session Management
Java server pages. A JSP file basically contains HTML, but with embedded JSP tags with snippets of Java code inside them. A JSP file basically contains.
Copyright © 2002 ProsoftTraining. All rights reserved. JavaServer Pages.
@2008 Huynh Ngoc Tin Chapter #2 JAVA SERVLET PRGRAMMING.
1 Web Servers (Chapter 21 – Pages( ) Outline 21.1 Introduction 21.2 HTTP Request Types 21.3 System Architecture.
1 WWW. 2 World Wide Web Major application protocol used on the Internet Simple interface Two concepts –Point –Click.
Java Servlets and Java Server Pages Norman White Stern School of Business.
1 Java Servlets l Servlets : programs that run within the context of a server, analogous to applets that run within the context of a browser. l Used to.
1 Introduction to Servlets. Topics Web Applications and the Java Server. HTTP protocol. Servlets 2.
JS (Java Servlets). Internet evolution [1] The internet Internet started of as a static content dispersal and delivery mechanism, where files residing.
Module: Software Engineering of Web Applications Chapter 2: Technologies 1.
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 JSP Application Models.
CSI 3125, Preliminaries, page 1 SERVLET. CSI 3125, Preliminaries, page 2 SERVLET A servlet is a server-side software program, written in Java code, that.
COMP9321 Web Application Engineering Semester 2, 2015 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 3 1COMP9321, 15s2, Week.
Internet Applications (Cont’d) Basic Internet Applications – World Wide Web (WWW) Browser Architecture Static Documents Dynamic Documents Active Documents.
8 Chapter Eight Server-side Scripts. 8 Chapter Objectives Create dynamic Web pages that retrieve and display database data using Active Server Pages Process.
ASP-2-1 SERVER AND CLIENT SIDE SCRITPING Colorado Technical University IT420 Tim Peterson.
UMass Lowell Computer Science Java and Distributed Computing Prof. Karen Daniels Fall, 2000 Lecture 21 Java Servlets Wed. 11/22/00 based on material.
HTTP protocol Java Servlets. HTTP protocol Web system communicates with end-user via HTTP protocol HTTP protocol methods: GET, POST, HEAD, PUT, OPTIONS,
Java Programming: Advanced Topics 1 Building Web Applications Chapter 13.
Bayu Priyambadha, S.Kom. Static content  Web Server delivers contents of a file (html) 1. Browser sends request to Web Server 3. Web Server sends HTML.
JAVA, JEE Training Introduction to Web Harinath Mallepally
Simple Web Services. Internet Basics The Internet is based on a communication protocol named TCP (Transmission Control Protocol) TCP allows programs running.
Web Development Web Servers.
Java Servlets By: Tejashri Udavant..
Java Servlets.
PHP / MySQL Introduction
Chapter 26 Servlets.
Servlet APIs Every servlet must implement javax.servlet.Servlet interface Most servlets implement the interface by extending one of these classes javax.servlet.GenericServlet.
Presentation transcript:

Testing Web-based applications Typically, a multi-layered architecture is used. Three primary layers, typically on different hosts: –Client: –often uses a web browser, but could also be an client application –sends requests for web pages –receives response –Database: –stores persistent data such as item catalogues, transaction records, etc. –Application server –receives requests and constructs a web page response –handles access control, session management, etc. Client Application server Database

The Client layer Web pages are represented by HTML, the HyperText Markup Language. The protocol to send and receive web pages from a web server is HTTP, the HyperText Transfer Protocol. What’s useful to know about HTTP in this context? –It was intended as a request – response protocol without any state. –It is entirely text-based and (somewhat) human-readable.

Application Servers Typical functions: –Management of concurrent sessions and transactions –Construction of dynamic and static web pages –Arrange for storage and retrieval of persistent data –Handling of business logic –Security

The Database interface The connection to a database via a programming language is via a connection protocol API (application programming interface): –ODBC: open database connectivity –JDBC: specific version for Java –Since databases are not compatible, there are normally specific drivers loaded in for each type of database (Oracle, MySQL, etc.) –Specify a URL such as jdbc:mysql://ste5007.site.uottawa.ca:3306/db to connect, and then provide a userid and password. After logging in, SQL (structured query language) commands are issued to insert, view, update, or delete data. Results from the database are loaded into a O/JDBC object for use.

For this presentation: Some assumptions on the environment for the purposes of this presentation: –Code is based on the Java Enterprise Edition (EE) software development kit, version 1.4 or earlier (i.e. not Java EE 5) –Use of a web application server that conforms to the Java EE specification

Java Application Servers Java EE servers use the concept of a “container” in which processing of a session is handled. Java classes are deployed into a container, and then interact with the container to provide functionality for the server. The container manages the creation and life cycle of the objects deployed within, and access to these objects.

Java Application Servers Container HTTP response, containing HTML HTTP request DB Application server Client / Browser Enterprise Java Bean (EJB) Java Server Page (JSP) Servlet Filter Tag Library

Server options Production-capable server: –Apache Tomcat, Sun JAS, Glassfish (for EE 5), JBoss, BEA, IBM WebSphere, Oracle Application Server, JOnAS,... Simplified server: –Jetty No server: –Mock object generator that provides mocks for the HTTP interface or the DB interface.

Testing the client If the purpose of testing is to test behaviour at the client, then various approaches are possible. –Use an actual production-capable application server (including possibly even the database layer). –Use an application server (perhaps a with stubs for web pages –Web pages are empty or nearly so, with no dynamic content. –Replace the application server with a stub or mock object that works with the HTTP protocol. The mock connection is the interface to the client. –Test client objects directly with JUnit.

Testing the client HTTP response, containing HTML HTTP request Client / Browser Embedded Application Server JUnit Test Case

Testing the client HTTP response, containing HTML HTTP request Client / Browser Mock Connection JUnit Test Case

HTTP primary commands GET: request a resource GET /~awilliam/csi5118 HTTP/1.1 Host: POST: submit data for processing POST /index.html HTTP/1.1 Host: Content-type: application/x-www-form-urlencoded... searchword=findme&option=search&submit=go File to retrieve Form data File from which data was posted

HTTP responses HTTP returns a numeric 3-digit code, header information, plus content. Frequent codes: –200 OK: request was satisfied, and message contains content. HTTP/ OK... Content-length: Content-type: text/html –404 Not found: the resource requested could not be located. Success Web page in HTML Content information

Potential test purposes at the Client Interface Check that when a user action occurs, the correct data is put into an HTTP request –Link has correct uniform resource locator (URL) address. –Data in POST command is as expected, and formatted correctly. Check that when an HTTP request is sent to the server, the response is as expected. –HTTP response is correct –HTML response is correct –Search for particular items within a web page to see if they are included (especially for dynamically generated pages) –Correct page –Correct page elements (buttons, etc.) –Data is as expected.

Sample: Web client that returns a string read from a web server public class WebClient { public String getContent( URL url ) { StringBuffer content = new StringBuffer(); try { HttpURLConnection connection = (HttpURLConnection) url.openConnection( ); connection.setDoInput( true ); InputStream is = connection.getInputStream( ); byte[] buffer = new byte[2048]; int count; while ( -1 != ( count = is.read( buffer ) ) ) { content.append( new String( buffer, 0, count ) ); } catch ( IOException e ) return null; return content.toString( ); }

Client test strategies To test this client, we have to arrange for some known data to appear from the URL, and be sure that the client reads it correctly. Two approaches: –Use an embedded server that we can control. –Use a stub or mock object for the connection.

Test strategy 1: Embedded server HTTP response, containing HTML HTTP request Client / Browser Embedded Application Server JUnit Test Case

Jetty Jetty is a small application server that can be embedded within a Java application. – For running JUnit, Jetty can be started within the same virtual machine. Jetty can be provided with various “contexts” and handlers –Essentially, a context defines a relative URL for which the Jetty server will accept requests. –Handlers tell Jetty how to construct responses.

Setup for Embedded Jetty Server public class WebClientTest { private static HttpServer public static void setUpBeforeClass( ) throws Exception { server = new HttpServer(); SocketListener listener = new SocketListener(); listener.setPort( 8080 ); server.addListener( listener ); HttpContext context1 = new HttpContext(); context1.setContextPath( "/testGetContentOK" ); context1.addHandler( new TestGetContentOKHandler() ); server.addContext( context1 ); HttpContext context2 = new HttpContext(); context2.setContextPath( "/testGetContentNotFound" ); context2.addHandler( new NotFoundHandler() ); server.addContext( context2 ); server.start( ); } URL for the context will be Handler for requests

Jetty Handlers public class TestGetContentOKHandler extends AbstractHttpHandler { public void handle( String pathInContext, String pathParams, HttpRequest theRequest, HttpResponse theResponse ) throws HttpException, IOException { OutputStream out = theResponse.getOutputStream( ); ByteArrayISO8859Writer writer = new ByteArrayISO8859Writer( ); writer.write( "It works" ); writer.flush( ); theResponse.setIntField( HttpFields.__ContentLength, writer.size( ) ); writer.writeTo( out ); out.flush( ); theRequest.setHandled( true ); }

Sample test + public void testGetContentOK( ) throws MalformedURLException { WebClient client = new WebClient( ); URL url = new URL(" String expected = "It works"; String actual = client.getContent( url ); assertEquals( expected, actual ); public static void tearDownAfterClass( ) throws Exception { server.stop(); }

Strategy 2: No server HTTP response, containing HTML HTTP request Client / Browser Stub Connection JUnit Test Case

Strategy 2: Implementation HTTP response, containing HTML HTTP request Client / Browser Stub URL Stream Handler JUnit Test Case URL Stub Stream Handler Factory Stub URL Connection

Stub for the URL connection public class StubHttpURLConnection extends HttpURLConnection { private boolean isInput = true; protected StubHttpURLConnection( URL url ) { super( url ); } public InputStream getInputStream( ) throws IOException { ByteArrayInputStream bais = new ByteArrayInputStream( new String( "It works" ).getBytes( ) ); return bais; }

Sample test + public static void setUpBeforeClass( ) throws Exception { URL.setURLStreamHandlerFactory( new StubStreamHandlerFactory() ); public void testGetContentOK( ) throws MalformedURLException { WebClient client = new WebClient( ); URL url = new URL(" String expected = "It works"; String actual = client.getContent( url ); assertEquals( expected, actual ); }

Testing Application Server Classes In-container approach: –This is the actual environment in which the class would be run. –Requires deploying classes to an application server (complex, time-consuming setup) –Access to classes for test purposes is restricted by the container. Out-of-container approach: –Requires stubs or mock objects for interactions with the container. –Not the actual running environment. –Once the container environment is simulated, tests can be run quickly.

Java Application Servers (reprise) Container HTTP response, containing HTML HTTP request DB Application server Client / Browser Enterprise Java Bean (EJB) Java Server Page (JSP) Servlet Filter Tag Library

Servlets Servlets are a mechanism for an application server to construct dynamic web page content. Example: –User enters a value into a text field on a web page and clicks a “submit” button. –An HTTP command is constructed by the browser and sent to the server. –The application server will parse the HTTP command, determine which session the command belongs to, and construct an HttpServletRequest object containing the request information. –The servlet’s function is to create an HttpServletResponse object that contains information needed to create the HTTP reply that contains the HTML to be displayed in the user’s browser.

The Servlet Environment Container Servlet HttpServletResponse HTTP response, containing HTML HttpServletRequest HTTP request DB Application server Browser

A (small) Sample Servlet Purpose: As part of handling a request, this method checks to see if the session associated with the request has stored a attribute indicating that the session was authenticated. public class SampleServlet extends HttpServlet implements Servlet { public boolean isAuthenticated( HttpServletRequest request ) { HttpSession session = request.getSession( false ); if ( session == null ) { return false; } String authenticationAttribute = ( String ) session.getAttribute( "authenticated" ); return Boolean.parseBoolean( authenticationAttribute ); }

How to test the Servlet? Because this method asks for the container’s session parameters, direct JUnit test cases are not possible in this environment. –The HttpServletRequest object is created by the container and is only available there. The request also must return a valid HttpSession to check the attribute. To test this code without the container, mock objects for the HttpServletRequest and HttpSession objects are needed.

Servlet Testing approaches Three ways of running test cases for this servlet will be shown here. 1.Out of container, using mock objects created by EasyMock. 2.In container, using the Apache Tomcat server and Cactus 3.In container, using the embeddable Jetty server and Cactus.

Out-of-container Strategy Servlet HttpServletResponse HttpServletRequest Mock DB JUnit Test Case

The sample servlet, again public class SampleServlet extends HttpServlet implements Servlet { public boolean isAuthenticated( HttpServletRequest request ) { HttpSession session = request.getSession( false ); if ( session == null ) { return false; } String authenticationAttribute = ( String ) session.getAttribute( "authenticated" ); return Boolean.parseBoolean( authenticationAttribute ); }

Mock objects test case – setup and teardown public class MockObjectTest { private SampleServlet servlet; private HttpServletRequest theRequest; private HttpSession public void setUp( ) throws Exception { servlet = new SampleServlet( ); theRequest = EasyMock.createMock(HttpServletRequest.class ); theSession = EasyMock.createMock( HttpSession.class ); public void tearDown( ) throws Exception { EasyMock.verify( theRequest ); EasyMock.verify( theSession ); }

Mock object test case – test public void testIsAuthenticatedTrue( ) { EasyMock.expect( theRequest.getSession( false ) ).andReturn( theSession ); EasyMock.expect( theSession.getAttribute("authenticated") ).andReturn("true"); EasyMock.replay( theRequest ); EasyMock.replay( theSession ); boolean expected = true; boolean actual = servlet.isAuthenticated( theRequest ); Assert.assertEquals( expected, actual ); }

Running the test case All the previous test case needs to run is to ensure the EasyMock class library is available. Tests are run without using an application server, and are run directly by JUnit. Advantages: –Test is easy to set up and will run quickly Disadvantages: –The test is not running in the actual servlet container, and we don’t know if the container will provide the correct request or not.

In-container Strategy (1) Container Servlet Response Request Test DB Application server JUnit Test Case

In-container Strategy (2) Container Servlet Response Request Test DB Application server JUnit Test Case JUnit Test Proxy

In-container testing with Cactus Cactus: part of the Apache Jakarta project –jakarta.apache.org/cactus Cactus is a framework to install a test component inside an application server, and to communicate with that test component. –Extension of the JUnit framework Result: You can run JUnit tests from outside the container, but have the tests executed inside the container.

How Cactus Works Cactus uses a proxy mechanism to run test cases at the client, and redirect the requests to a copy of the test case inside the server container.

In-container testing with Cactus What is required: 1.Include the JUnit and Cactus libraries as part of the deployment to the application server container. 2.Implement a client redirector that takes a JUnit test case run outside the container, and duplicate it within the container. 3.Implement a server redirector that lets Cactus intercept incoming requests during test case execution and provide them as objects to the test case. 4.Provide a mechanism to get the test case results back from the container to the test runner.

Cactus JUnit test cases Test class must inherit from one of the following classes: –org.apache.cactus.ServletTestCase, to test a servlet –org.apache.cactus.FilterTestCase, to test a filter –org.apache.cactus.JspTestCase, to test a Java server page

Cactus JUnit test cases For a servlet test case, the JUnit test case will have access to the following objects: –request –response –config –session The servlet context can also be accessed indirectly.

Structure of a Cactus test begin(), end() : executed on the client side before and after each test case setUp(), tearDown() : executed on the server side before and after each test case testXXX() : a test method, to be executed within the server container beginXXX(WebRequest request) : a method to be executed on the client immediately before testXXX(). –The parameter is used to set up the request to be passed to the server. endXXX(WebResponse theResponse ): a method to be executed at the client immediately after testXXX(). This is used to verify the HTTP response from the user.

How Cactus Works Here is the order of execution of the various methods:

First In-Container Test Project Goal: Execute a servlet test case on an Apache Tomcat application server. Create an Eclipse “dynamic web” project –The target server is defined at project creation time. –Eclipse will create the web.xml deployment descriptor for the project. –Using the servlet wizard to create the servlet will add the servlet to the deployment descriptor

Additions to Deployment Descriptor Cactus redirectors must be added to the web.xml file, so that they can be part of the project deployment. ServletRedirector org.apache.cactus.server.ServletTestRedirector ServletRedirector /ServletRedirector

Test class, part 1 public class TomcatCactusTest extends ServletTestCase { private SampleServlet public void setUp( ) throws Exception { servlet = new SampleServlet( ); public void testIsAuthenticatedTrue( ) { session.setAttribute( "authenticated", "true" ); boolean actual = servlet.isAuthenticated( request ); boolean expected = true; assertEquals( expected, actual ); }

Test class, part public void testIsAuthenticatedFalse( ) { boolean actual = servlet.isAuthenticated( request ); boolean expected = false; assertEquals( expected, actual ); } public void beginIsAuthenticatedNoSession( WebRequest theRequest ) { theRequest.setAutomaticSession( false ); public void testIsAuthenticatedNoSession( ) { boolean actual = servlet.isAuthenticated( request ); boolean expected = false; assertEquals( expected, actual ); }

Eclipse view of project with Cactus deployment descriptor

Libraries needed For the client: –junit.jar [from JUnit] –servlet-api.jar [from target Application Server] –cactus.jar –aspectjrt.jar –commons-httpclient.jar –commons-logging.jar For the server: –junit.jar [from JUnit] –Application server libraries –cactus.jar –aspectjrt.jar –commons-logging.jar

Libraries added to Eclipse project for Cactus

Test run on Tomcat Server

Cactus + Jetty Cactus is used to run test cases inside the container provided by Jetty. Jetty can run the previous servlet test case that was run on the Tomcat server. Since Jetty is embedded, the server will be started by the test case. –Cactus provides a wrapper to set up tests within Jetty by doing a combined server start- up and test case deployment.

Cactus test wrapped for Jetty // line is needed for JUnit 4 to run test AllTests.class ) public class JettyCactusTest { public static Test suite( ) { // The next line adapts a JUnit 4 test for a JUnit 3 runner Test suite3 = new JUnit4TestAdapter( TomcatCactusTest.class ); System.setProperty( "cactus.contextURL", " ); TestSuite suite = new TestSuite( "All tests with Jetty" ); suite.addTest( suite3 ); return new JettyTestSetup( suite ); }

Test run on embedded Jetty server