Skip navigation.
Home

Archives

Pylot 1.11 Released - Web Performance Tool

Submitted by noreply@blogger.com (Corey Goldberg) on Wed, 27/08/2008 - 14:06.
I just did a new release Pylot (Web Performance Tool). No new features; just some internal fixes and a small change to the console output.

Grab it here: http://pylt.googlecode.com/files/pylot_1.11.zip

Pylot Home: www.pylot.org
» login or register to post comments | feed | read more

Root Cause of Singletons

Submitted by noreply@blogger.com (Misko) on Wed, 27/08/2008 - 17:41.
by Miško Hevery

Since I have gotten lots of love/hate mail on the Singletons are Pathological Liars and Where Have All the Singletons Gone I feel obliged to to do some root cause analysis.
» login or register to post comments | feed | read more

Taming the Beast (a.k.a. how to test AJAX applications) : Part 2

Submitted by noreply@blogger.com (John Thomas) on Thu, 28/08/2008 - 02:41.

Posted by John Thomas and Markus Clermont

This is the second of a two part blog series titled 'Taming the Beast : How to test AJAX applications'. In part one we discussed some philosophies around web application testing. In this part we walk through a real example of designing a test strategy for an AJAX application by going 'beyond the GUI'.

Application under test

The sample application we want to test is a simple inventory management system that allows users to increase or decrease the number of parts at various store locations. The application is built using GWT (Google Web Toolkit) but the testing methodology described here could be applied to any AJAX application.

To quickly recap from part one, here's our recipe for testing goodness:
  1. Explore the system's functionality
  2. Identify the system's architecture
  3. Identify the interfaces between components
  4. Identify dependencies and fault conditions
  5. For each function
    1. Identify the participating components
    2. Identify potential problems
    3. Test in isolation for problems
    4. Create a 'happy path' test
Let's look at each step in detail:

1. Explore the system's functionality

Simple as this sounds, it is a crucial first step to testing the application. You need to know how the system functions from a user's perspective before you can begin writing tests. Open the app, browse around, click on buttons and links and just get a 'feel' of the app. Here's what our example app looks like:
The app has a NavPane to filter the inventory by locations, list number of items in each location, increase/decrease the balance for items and sort the list by office and by product.


2. Identify the architecture

Learning about the system architecture is the next critical step. At this point think of the system as a set of components and figure out how they talk to each other. Design documents and architecture diagrams are helpful in this step. In our example we have the following components:
  • GWT client: Java code compiled into JavaScript that lives in the users browser. Communicates with the server via HTTP-RPC
  • Servlet: standard Apache Tomcat servlet that serves the "frontend.html" (main page) with the injected JavaScript and also serves RPCs to communicate with the client-side JavaScript.
  • Server-side implementation of the RPC-Stubs: The servlet dispatches the RPC over HTTP calls to this implementation. The RPCImpl communicates with the RPC-Backend via protocol-buffers over RPC
  • RPC backend: deals with the business logic and data storage.
  • Bigtable: for storing data
It helps to draw a simple diagram representing the data flows between these components, if one doesn't already exist:

In our sample application, the RPC-Implementation is called "StoreService" and the other RPC-Backend is called "OfficeBackend".

» login or register to post comments | feed | read more