Beaches and Parking Case Study

Event Testing Theory

In object oriented environment, an event can be defined as a signal from the system to the program that something has happened. Events can be things such as mouse clicks, mouse movements, keyboard key presses or any user defined event types. In order to take effect, those events have to be delivered and interpreted by the run time system. As the result, one or more messages are generated. These messages contain information about those events which are then delivered to the interested objects.

These objects are often referred as listener objects. These objects will have to register themselves to enable them to receive the  messages together with the event handler function. The messages are then mapped to find out which function/method to perform appropriate actions. This new approach of programming is usually called event driven programming as opposed to the traditional procedural approach.

In the traditional approach (procedure driven programming) the program is in control. The execution starts at the top of the program and then follows the control flow in a predictable manner. The user is usually a passive participant. This is not a practical approach for interactive environment where a lot of user interaction is needed. Event driven programming allows user to be in control. The user is able to select any actions she/he would like to execute. Things like menu item selection, clicking on buttons, etc.

One way to view this approach is to picture the program as a collection of event handlers that are executed when events occur. Therefore, in event driven programming, there is no predetermined script. The user is an active participant.

The message passing process follows the parent-to-child hierarchy. The operating system, which controls all of the system resources such as memory, storage driver, and etc, detects that an event has occurred. The event is translated into messages and directed to the application. In a multitasking environment where there may be more than one application running at the same time, the active application is the target since there can be only one active application. However, this does not necessarily be the case. Then the application may choose to ignore or respond to the message. The message may also be passed to its components.

In relation to the case study implementation, there are a few things that need to be mentioned as there are a few aspects which are specific to Java environment. The Java Development Kit (JDK) comes with a set of standard libraries contained in several packages. These libraries are what often referred to as the Applications Programming Interface (API).  Each package embodies several related classes and interfaces. Classes and Interfaces are two different types of object in Java. A class may contain the data and methods where interfaces only contains signature of methods which must be defined by the objects implementing the interface.

Abstract Windowing Tool kit (AWT) is one of the library that comes with the JDK and it is a collection of classes that are used to create the GUI components. Another important component of the AWT package is the java.awt.event. This package defines the standard event objects that come with Java and the interfaces for them. So in order to receive  a particular event, the listener object must implement the appropriate interface. For instance, an applet contains several buttons wants to respond to a mouse click on one of the buttons. It must then implement the MouseListener interface and define every methods in the interface. There are fivemethods declared in it. Define the mouseClicked() method to handle the event. To complete the process, the button must register its parent, that is the applet as a listener to mouse events via the call of Component.addMouseListener() (Component is the parent class of Button).

The Java run-time environment generates an event object for each message. The object contains various information such as the component from which the message is originated. However it is really up to the applet how it responds to the message in a sense that the applet may have to determine which action to take depending upon the message source. In AWT, events may be generated from the following sources:

• user input

The keyboard (text field); The mouse (button, mouse movements) Scroll bar activities; List box item selection and deselection; Change of input focus; Component and menu actions, etc.

• system generated

Window creation, destruction; etc.

Having mentioned all of the information above, it can be summarized that the purpose of event testing is to make sure the messages from events are mapped to the right handlers and that the handlers behave in a predictable manner. For instance when  the File-Open menu item is selected, the application brings up the file selection dialog box not the help window. And no matter how many time the method is called, it should produce the same result assuming everything else remains the same.

The Black box method can also be used which means the system tester calls the event handler to see if it produces the expected result without knowing the process behind the scene. The system can be tested without having to depend on the user to take actions. The system can be tested using an automated event generator. The event generator may be the object itself or another object that especially designed for testing purposes.