Download Testing Java components - Dr Sharmin (Tinni) Choudhury

05/14/17
Software Verification and Research Centre
The University of Queensland
Testing Java components
SVRC Summer research project
Sharmin Choudhury
Supervisor: Dr. Paul Strooper
Friday, 23rd of February 2001
1
05/14/17
Contents
1. Introduction
3
2. Related Work
3
3. Properties of JavaBeans
4
4. The symtbl
4
5. Test Plan symtbl
6
6. Developing a test plan for symtbl
7
7. Roast script for symtbl
7
8. Creating an symtbl JavaBean
8
9. Test Plan symtblBean
12
10. Testing plan for symtblBean
13
11. Roast script for symtblBean
15
12. Conclusion
16
13. Bibliography
17
2
05/14/17
Introduction
The object-oriented programming language Java has in recent years gained in popularity due to its
ability to allow the execution of an applet from within a web browser. Its ease of portability and
platform-independent status also assisted with its popularity.
Object-oriented languages are closely associated with a high level of code reuse. This high code reuse
makes it imperative that effective testing strategies are developed for both Java in general and
JavaBeans components, which are reusable software components.
JavaBeans is a portable, platform-independent component model written in the Java programming
language that allows programmers to develop JavaBeans components or Beans. A JavaBeans
component or a Bean is a reusable software component that can be manipulated visually in a builder
tool. For the testing of JavaBeans, Sun Microsystems, the makers of Java and JavaBeans, have
developed the Beanbox. The Beanbox is a test container to allow JavaBeans developers to test and
evaluate Bean behaviour. This is likely to aid greatly in Bean testing, but generally Beans are harder to
test than ordinary classes as they tend to interact heavily with their environment. It is still a relatively
new concept for even Java programmers. Thus only a few strategies exist for testing them. But as
JavaBeans components become more and more popular, it becomes necessary to develop effective
testing strategies for testing Java classes and JavaBeans.
In this project, a testing strategy will be developed for JavaBeans with reference to testing Java
programs in general. Testing strategies will be explored and developed using a simple Java program as
an example. In this case, the program of choice is a simple symbol table program called symtbl.
Originally programmed in C, for the purposes of his project it will be converted to Java with as little
functional alteration as possible.
Once an acceptable testing strategy has been developed for general Java classes, it will be extended so
that it may be applied to JavaBeans. In developing a strategy the project will concentrate on Black box
unit testing as it appears to be the best method of testing object-oriented programs.
Related Work
Donovan [1] in his honours project investigated approaches for testing methods developed for other
object-oriented languages, to see if they worked equally well with Java. He focused on unit testing and
endeavoured to confirm that testing in Java is as feasible as in other object-oriented languages. He
compared and evaluated a number of Java testing tools against a set criterion. The criterion was
designed to evaluate which of the tools would be most suitable for testing JavaBeans. Furthermore the
project aimed to identify the concepts and composition of a JavaBean by focusing on defining software
components and relating this definition to the JavaBeans specification. An evaluation was made to
determine if it was feasible to test a Bean with approaches that were developed for class testing in
Donovan’s project as well.
The simple Java class used by Donovan for evaluation of the different testing tools was an integer stack
program called IntStack [1]. This class was used to compare and evaluate between a hand-coded test
driver, a Roast script [3] and the commercially available testing tool JavaSpec. He concluded that the
Roast script driver was the best choice out of the three when it came to testing Java classes. Due to the
limited time available for the current project, a new comparison of different testing tools will not be
made. Donovan’s conclusion will be accepted and Roast will be used for all testing [1].
3
05/14/17
In relation to JavaBeans, Donovan found that the difference that exists between Java classes and
JavaBeans gives rise to problems that formed barriers towards directly applying the testing strategies
developed for Java classes to JavaBeans [1]. However, he was able to modify them so that they did
extend to JavaBeans. He found that he needed to add a listener Bean that works in conjunction with the
test driver to test JavaBeans properly. The listener Bean is responsible for capturing all of the events
that are fired and allows the test driver to access the event data for verification purposes. The Beans he
tested were integer stack Bean, which was a converted IntStack class, and a commercially available
integer array Bean.
Properties of JavaBeans
A JavaBean is a reusable software component that can be manipulated visually in a builder tool. The
builder tool can be a web page builder, a visual application builder, a GUI layout builder, or even an
application builder. The beans themselves can range from simple GUI elements such as buttons and
sliders to sophisticated database viewers or data feeds [4].
Individual Java Beans will vary in functionality, but most share the following features [4].
 Support for introspection allowing a builder tool to analyse how a bean works.
 Support for customisation allowing a user to alter the appearance and behaviour of a bean.
 Support for events allowing beans to fire events, to inform builder tools about both the events
they can fire and the events they can handle.
 Support for properties allowing beans to be manipulated programmatically, as well as to
support the customisation mentioned above.
 Support for persistence allowing beans that have been customised in an application builder to
have their state saved and restored. Typically persistence is used with an application builder's
save and load menu commands to restore any work that has gone into constructing an
application.
The design environment for a Java Bean is a builder tool, and a Bean must be able to run inside a
builder tool. Each bean must also be usable within the generated application at run-time.
The symtbl
The symtbl program is a simple Java program that constructs a table of symbols. A symbol is defined as
a string-integer pair. The table may only contain a certain number of symbols, as defined by the
constant “ST_MAXSYMS”. The symbols can be composed of any string and any integer. The interface
for the symtbl is shown below in figure 1.
public class symtbl{
public int ST_MAXSYMS = 5;
public symtbl();
public void st_s_add (String sym, int loc) throws symbolFoundException, maxSymbolException;
public boolean st_g_exsym (String sym);
public void st_s_locv (String sym, int loc) throws symbolNotFoundException;
public int st_g_loc (String sym) throws symbolNotFoundException;
public int st_g_siz ();
public void st_g_dump ();
public static void main (String [] args) throws Exception;
4
05/14/17
}
Figure 1: Symtbl interface
The methods contained within the class allow the addition of new symbols to the table, to determine if
a given string forms a component of any of the existing symbols within the table, and to return and
change the integer part of an existing symbol. There is also a method that returns the current size of the
table. Finally, there is a print method that is used for debugging purposes.
Also three special exception classes were defined in order to handle the expected exceptions generated
by the symtbl. These were the maxSymbolException class, this exception is to be thrown when an
attempt is made to add more than the maximum number of symbols allowed to a symbol table. The
symbolFoundException class, this is to be thrown when an attempt is made to add a pre-existing
symbol. Lastly the symbolNotFoundException class, which is to be thrown when a symbol that is
expected to exist, does not.
The conversion from C to Java of the symtbl posed some problems. To solve some of the more pressing
problems a new class needed to be constructed. This class is responsible for creating the symbol objects
that populate the symbol table constructed by symtbl. It is a simple class that does not alter the function
of the symtbl to a great extent. The interface for this class is given in figure 2.
public class sym {
public String sym;
public int loc;
public sym (String symbol, int location);
}
Figure 2: Sym interface
5
05/14/17
Test Plan for symtbl
Assumptions
Maximum number of symbols allowed is equal to five.
Test Environment
Roast Script
Test Case selection strategy
Special Value
Boundary value rule on [1, Max symbol]
Symbols that exist in table
Symbol that does not exist in table
Test cases
For each special value
Methods
Test case One
Tests the addition of one symbol to a previously empty table and checks to
ensure that the length of the table is correct.
Test case Two
Tests the addition of three symbols to a previously empty table and checks
to ensure that the length of the table is correct.
Test case Three
Tests the addition of five symbols to a previously empty table and checks to
ensure that the length of the table is correct.
Test case Four
Test to ensure that an exception is correctly thrown when an attempt is made
to add more than the allowed number of symbols to the table.
Test case Five
Test to ensure that an exception is correctly thrown when an attempt is made
to add a pre-existing symbol to the table.
Test case Six
Test to see if the correct boolean value is returned when the method that
checks to see if a certain symbol exists in the table is called.
Test case Seven
Ensures that the correct value is returned when the method that returns the
integer component of an existing symbol is called. Also ensures that the
correct exception is thrown when the symbol, whose integer component is
to be returned, doesn’t exist.
Test case Eight
Ensures that no exception is generated when an attempt is made to change
the integer component of an existing symbol in the table. Than checks to see
6
05/14/17
that the integer component was correctly altered. Also ensures that an
exception is generated when an attempt is made to change the integer
component of a non-existing symbol in the table.
Developing a test plan for symtbl
After the conversion of the symtbl was completed a number of test cases were generated using the
black box testing method. Black box testing is a type of unit testing that is also known as functional
testing. This manner of testing is concerned with testing for a specified behaviour for a module or class
without referring to its code. The input to a module or class usually takes the form of parameters that
are selected in reference to the specification. The selection of the parameters is usually guided by a
number of principles. Generally they contain at least some boundary values, one value in the middle
and at least some values that are meant to generate exceptions. Roast is a testing tool that supports the
black box testing principle.
For the primary testing of the symtbl the maximum length of the table was set to five. Four parameters
were chosen to test the symtbl, these parameters were one symbol, three symbols, five symbols and six
symbols.
The first three parameters were designed to test the normal behaviour of the symtbl. No exceptions
were expected when the symbols were added and the size of the table was expected to be equal to the
number of symbols added thus far. The first three test cases thus checked that symbols were added
correctly to the symbol table. Test cases four and five were used to check the two exception conditions
of the st_s_add method. For the remaining test cases it was assumed that the table is fully loaded.
Test case six was designed to test that the symtbl correctly identifies whether a symbol exists or not. As
such, two value checking tests are included. One for a symbols that was known to exist in the table and
one for a symbol that was known not to exist in the table.
Test seven consists of two parts. The first part checks that the integer component of a symbol returned
by the symtbl, given the string component. The second part checks that the symtbl returned the
symbolNotFoundException if the symbol with the supplied string component does not exist.
Test case eight is divided into three parts. The fist part is an exception-monitoring test that ensures that
the integer component of a symbol is changed without generating any exceptions. The second part
consists of a value-checking test in which it is confirmed that the change that needed to be made was
indeed made. The third part was used to make sure that if a symbol, which does not exist, was passed to
the method then an exception was generated. The test script for all the test cases is shown in figure 3.
As the print method for the symtbl is for de-bugging purposes it is not tested.
public class symtbl_driver {
public static void main (String [] args) {
//Objects needed for testing
symtbl symbol = new symtbl();
//Test case one
7
05/14/17
#excMonitor symbol.st_s_add("Tinni", 1); #end
#valueCheck symbol.st_g_siz() # 1 #end
//Test case two
#excMonitor symbol.st_s_add("Adnan", 2); #end
#excMonitor symbol.st_s_add("Trunks",33); #end
#valueCheck symbol.st_g_siz() # 3 #end
//Test case three
#excMonitor symbol.st_s_add("Vegeta",4); #end
#excMonitor symbol.st_s_add("Bulma", 5); #end
#valueCheck symbol.st_g_siz() # 5 #end
//Test case four
#excMonitor symbol.st_s_add("Error", 6); # new maxSymbolException() #end
//Test case five
#excMonitor symbol.st_s_add("Bulma", 5); # new symbolFoundException() #end
//Test case six
#valueCheck symbol.st_g_exsym("Vegeta") # true #end
#valueCheck symbol.st_g_exsym("Nothing") # false #end
//Test case seven
#valueCheck symbol.st_g_loc("Tinni") # 1 #end
#excMonitor symbol.st_g_loc("Error"); # new symbolNotFoundException() #end
//Test case eight
#excMonitor symbol.st_s_locv("Trunks", 3); #end
#valueCheck symbol.st_g_loc("Trunks") # 3 #end
#excMonitor symbol.st_s_locv("Error", 7); # new symbolNotFoundException() #end
//Method call for debugging purposes
symbol.st_g_dump();
}
}
Figure 3: Roast Testing Script for symtbl
Creating an symtbl JavaBean
In order to develop a testing strategy for JavaBeans the first thing needed was a JavaBean. The best
choice for a Bean for testing was to convert the symtbl into a JavaBean, symtblBean. To do so it was
necessary for the symtblBean to contain examples of the three fundamental aspects of a JavaBean and a
BeanInfo class for introspective purposes. The new symtblBean was created following the steps
outlined by Donovan in his thesis when he converted his simple Java class to a JavaBean [1].
The first step towards creating a symtblBean was that the specification for the original symtbl needed to
be changed so as to allow support for the JavaBean framework. The main required specifications
8
05/14/17
include a no-argument constructor, implementing the java.io.Serializable interface and that a JavaBean
must be security and thread conscious. The symtblBean specification is given below.
public class symtblBean{
public symtbl();
public synchronized void st_s_add (String sym, int loc) throws symbolFoundException, maxSymbolException;
public synchronized boolean st_g_exsym (String sym);
public synchronized void st_s_locv (String sym, int loc) throws symbolNotFoundException;
public synchronized int st_g_loc (String sym) throws symbolNotFoundException;
public synchronized int st_g_siz ();
public synchronized void st_g_dump ();
public synchronized int getST_MAXSYMS ();
public synchronized void setST_MAXSYMS(int n);
public static void main (String [] args) throws Exception;
}
Figure 4: symtblBean specification
To allow for a JavaBean that was more along the lines of the JavaBeans specification meant that
symtblBean should contain at least one property. The original symtbl had no properties but the
ST_MAXSYMS could easily be converted into a property but at the same time two additional methods,
getST_MAXSYMS (), setST_MAXSYMS (int n), were required for getting and setting this property.
This property is a bounded property. For the last requirement, JavaBeans must be security and thread
conscious, to be met the reserved word synchronized was added to each method, indication that if any
method from symtblBean is currently under execution then no other methods from this class can be
executed concurrently.
In order for testing methodology to accommodate all fundamentals of JavaBeans it was necessary to
added events to symtbl. Two events were added to the symtblBean. The first event was a trivial event
called ChangeSymtblEvent. It is fired every time an internal structural change occurs within the symtbl,
such as adding a new symbol. The ChangeSymtblEvent has an attribute, date, which any listener object
has access to, using the access method getDate. The date attribute plays no significance in the
symtblBean implementation but it is used for creating an event that contains some data. The entire class
for ChangeSymtblEvent is listed in Figure 5.
/** The ChangeSymtblEven class is an event that is fired when the internal
* data structure an IntStackBean changes.
* author Tinni Choudhury
* February 2001
*/
import java.util.*;
public class ChangeSymtblEvent extends EventObject {
private long date;
public ChangeSymtblEvent (Object source){
super(source);
9
05/14/17
date = System.currentTimeMillis();
}
public long getDate() {
return date;
}
}
Figure 5: The ChangeSymtblEvent
To handle this event a list of listener objects need to be maintained in symtblBean so that when the
symtblBean changes a notification can be sent by the private method notifyListeners to all the registered
listeners. In order to maintain a list of listeners, add and remove listener methods were added to the
original symtblBean specification. All registered listeners must implement a symtblBeanListener
interface in order to receive notifications of events. This interface is given below.
import java.util.*;
public interface symtblBeanListener extends java.util.EventListener {
/** Changed is the method all listeners of an symtblBean must
* implement */
public abstract void changed(ChangeSymtblEvent e);
}
Figure 6: The symtblBeanListener
The second event that was added to the symtblBean is related to the bounded property ST_MAXSYMS.
JavaBeans has pre-built functionality that is similar to that described previously for the
ChangeSymtblEvent except, that it is only for bound and constrained properties. The
PropertyChangeEvent along with its related classes and interfaces allows the easy addition of bound
properties
to
JavaBeans.
Two
new
methods,
addPropertyChangeListener
and
removePropertyChangeListener, were added to symtbl for registering listeners for the bound property
ST_MAXSYMS. Below is the final symtblBean specification.
public class symtblBean{
public symtbl();
public synchronized void addSymtblBeanListener (symtblBeanListener l);
public synchronized void removeSymtblBeanListener(symtblBeanListener l);
public synchronized void addPropertyChangeListener (PropertyChangeListener p);
public synchronized void removePropertyChangeListener (PropertyChangeListener p);
public synchronized void st_s_add (String sym, int loc) throws symbolFoundException, maxSymbolException;
public synchronized boolean st_g_exsym (String sym);
public synchronized void st_s_locv (String sym, int loc) throws symbolNotFoundException;
public synchronized int st_g_loc (String sym) throws symbolNotFoundException;
public synchronized int st_g_siz ();
public synchronized void st_g_dump ();
public synchronized int getST_MAXSYMS ();
10
05/14/17
public synchronized void setST_MAXSYMS(int n);
public static void main (String [] args) throws Exception;
}
Figure 7: The symtblBean specification
The addition of introspection for the symtblBean was accomplished using a BeanInfo class called
symtblBeanBeanInfo. The BeanInfo class was constructed in similar fashion as the one created by
Donovan in his thesis [1]. The BeanInfo class lists the properties, events and methods that the
programmer decides are relevant for other components. The symtblBeanBeanInfo class does not
implement BeanInfo class but inherits simpleBeanInfo, which is an implementation of BeanInfo
interface with empty method bodies, allowing the programmer to implement only the methods that the
programmer requires. The two methods implemented in symtblBeanBeanInfo is getIcon, used to
specify a link to a GIF image that is to be used as an icon for the bean in a builder tool, and
getDescriptors method, which returns an array of PropertyDescriptors that contain labels for
presentation in a builder tool as well as the class that the property belongs to. The entire class is given
below.
import java.beans.*;
public class symtblBeanBeanInfo extends simpleBeanInfo {
public java.awt.image getIcon (int iconKind){
return loadImage("Goku5.gif");
}
public PropertyDescriptor[] getPropertyDescriptors() {
try {
PropertyDescriptor pd = new PropertyDescriptor("ST_MAXSYMS", symtblBean.class);
pd.setBound(true);
return new PropertyDescriptor [] {pd};
} catch (Exception e) {
return null;
}
}
}
Figure 8: The symtblBeanBeanInfo class
11
05/14/17
Test Plan for symtblBean
Assumptions
Maximum number of symbols allowed is equal to five.
Test Environment
Roast Script
Test Case selection strategy
Special Value
Boundary value rule on [1, Max symbol]
Symbols that exist in table
Symbol that does not exist in table
Test cases
For each special value
Methods
Test case One
Tests the addition of one symbol to a previously empty table and checks to
ensure that the length of the table is correct.
Test case Two
Tests the addition of three symbols to a previously empty table and checks to
ensure that the length of the table is correct.
Test case Three
Tests the addition of five symbols to a previously empty table and checks to
ensure that the length of the table is correct.
Test case Four
Test to ensure that an exception is correctly thrown when an attempt is made to
add more than the allowed number of symbols to the table.
Test case Five
Test to ensure that an exception is correctly thrown when an attempt is made to
add a pre-existing symbol to the table.
Test case Six
Test to see if the correct boolean value is returned when the method that checks
to see if a certain symbol exists in the table is called.
Test case Seven
Ensures that the correct value is returned when the method that returns the
integer component of an existing symbol is called. Also ensures that the correct
exception is thrown when the symbol, whose integer component is to be
returned, doesn’t exist.
Test case Eight
Ensures that no exception is generated when an attempt is made to change the
integer component of an existing symbol in the table. Than checks to see that the
12
05/14/17
integer component was correctly altered. Also ensures that an exception is
generated when an attempt is made to change the integer component of a nonexisting symbol in the table.
Test case Nine
Ensures that the correct value is returned by the getST_MAXSYMS() method.
Test case Ten
Ensures that no exception in generated when an attempt is made to set the
ST_MAXSYMS property. Than checks to see if the value of ST_MAXSYMS
has been changed properly.
Events
Test case Eleven
Checks to see if the property change event was fired correctly given the change
of property event executed in test ten.
Test case Twelve
Checks to see if the ChangSymtblEvent is fired correctly.
The testing plan for symtblBean
The testing plain for symtblBean contains all the test cases that were used in testing the class symtbl. As
all the methods that are present in the class symtbl is also present in symtblBean all of these test cases
are needed. But new test cases are also needed to test the methods that were added to the symtblBean
and also to test that events are fired correctly by the bean. In order to test whether or not the events
were fired correctly a listener bean was developed. This listener bean is called symtblListenerStub. The
listener bean allows the test driver to access the event data for verification purposes as well as capture
all events that are fired.
symtblListenerStub contains a property change listener that is notified whenever the ST_MAXSYMS
property of the symtblBean bean is changed and symtblListenerStub also contains a change stack event
listener that is notified whenever the ChangeSymtblEvent is fired. The symtblBean and
symtblListenerStub was wired together by adding symtblListenerStub to the list of interested listeners
kept in symtblBean. The entire class is given below.
import java.io.*;
import java.beans.*;
import java.lang.*;
public class symtblListenerStub implements Serializable,
symtblBeanListener {
PropertyChangeListener,
private int oldValue, newValue;
String propertyName;
Private long olddate = 0, date;
/* Accessories for PropertyChangeEvent */
13
05/14/17
public int getOldValue() {
return oldValue;
}
public int getNewValue() {
return newValue;
}
public String getPropertyName() {
return propertyName;
}
/* Accessories for the ChangeStackEvent */
public boolean getDate() {
if (olddate <= date){
return true;
} else {
return false;
}
}
/* Implements the PropertyChangeListener interface */
public void propertyChange(PropertyChangeEvent evt){
propertyName = evt.getPropertyName();
Integer intOld = new Integer(1);
Integer intNew = new Integer(1);
intOld = (Integer)(evt.getOldValue());
intNew = (Integer)(evt.getNewValue());
oldValue = intOld.intValue();
newValue = intNew.intValue();
}
public void changed(ChangeSymtblEvent e){
olddate = date;
date = e.getDate();
}
}
Figure 9: The symtblListenerStub bean
In total four new test cases were added to the roast testing script for symtbl. Test cases nine and ten
were added to test the methods get and set for the bounded property ST_MAXSYMS. Test case nine
determined if the value returned by the getST_MAXSYMS () method was indeed correct and test case
ten was designed to determine if the setST_MAXSYMS () method set the ST_MAXSYMS bounded
property without generating any unexpected exceptions. Test case ten also determined if the value
ST_MAXSYMS was set to was the value that it was suppose to be set to.
14
05/14/17
Test case eleven and twelve were designed to test the event aspect of the symtblBean. Test case eleven
determined if the Property change event was fired correctly when the ST_MAXSYMS bounded
property was changed. Similarly test case twelve was designed to see if the ChangeSymtblEvent fired
properly.
It must be noted here that though symtblBean passed the first ten test cases it did not pass test case
eleven however it did pass test case twelve. The problem is most likely to do with the fact that the
symtblListenerStub is not receiving proper notification of PropertyChangeEvent from symtblBean
when the bounded property ST_MAXSYMS is changed. The problem could either be due to the
structure of symtblListenerStub or it could be due to something that is wrong with symtblBean.
However not enough time was available to correct this fault. The full test script for symtblBean is given
below.
public class symtblBeanDriver {
public static void main (String [] args){
//JavaBean under test
symtblBean symbol = new symtblBean();
// The listener stubs
symtblListenerStub l = new symtblListenerStub();
//Used for catching bounded property events;
PropertyChangeAdapter adapter = new PropertyChangeAdapter();
//Adding the adapter and listener
symbol.addPropertyChangeListener(adapter);
symbol.addSymtblBeanListener(l);
//Test case one
#excMonitor symbol.st_s_add("Tinni", 1); #end
#valueCheck symbol.st_g_siz() # 1 #end
//Test case two
#excMonitor symbol.st_s_add("Adnan", 2); #end
#excMonitor symbol.st_s_add("Trunks",33); #end
#valueCheck symbol.st_g_siz() # 3 #end
//Test case three
#excMonitor symbol.st_s_add("Vegeta",4); #end
#excMonitor symbol.st_s_add("Bulma", 5); #end
#valueCheck symbol.st_g_siz() # 5 #end
//Test case four
#excMonitor symbol.st_s_add("Error", 6); # new maxSymbolException() #end
//Test case five
#excMonitor symbol.st_s_add("Bulma", 5); # new symbolFoundException() #end
15
05/14/17
//Test case six
#valueCheck symbol.st_g_exsym("Vegeta") # true #end
#valueCheck symbol.st_g_exsym("Nothing") # false #end
//Test case seven
#valueCheck symbol.st_g_loc("Tinni") # 1 #end
#excMonitor symbol.st_g_loc("Error"); # new symbolNotFoundException() #end
//Test case eight
#excMonitor symbol.st_s_locv("Trunks", 3); #end
#valueCheck symbol.st_g_loc("Trunks") # 3 #end
#excMonitor symbol.st_s_locv("Error", 7); # new symbolNotFoundException() #end
//Test case nine
#valueCheck symbol.getST_MAXSYMS() # 5 #end
//Test case ten
#excMonitor symbol.setST_MAXSYMS(6); #end
#valueCheck symbol.getST_MAXSYMS() # 6 #end
//Test case eleven
#valueCheck l.getNewValue() # symbol.getST_MAXSYMS() #end
//Test case twelve
#excMonitor symbol.st_s_add("Tinni", 1); #end
#valueCheck l.getDate() # true #end
#excMonitor symbol.st_s_add("Vegeta", 2); #end
#valueCheck l.getDate() # true #end
#excMonitor symbol.st_s_add("Bulma", 3); #end
#valueCheck l.getDate() # true #end
#excMonitor symbol.st_s_add("Trunks", 4); #end
#valueCheck l.getDate() # true #end
#excMonitor symbol.st_s_add("Adnan", 5); #end
#valueCheck l.getDate() # true #end
#excMonitor symbol.st_s_add("Goten", 6); #end
#valueCheck l.getDate() # true #end
//Method call for debugging purposes
symbol.st_g_dump();
}
}
Figure 10: Roast testing script for symtblBean
Conclusion
Testing strategies and methodologies for Java in general and its new reusable software component
JavaBeans is not as well developed as other programming languages due to its relatively recent
introduction into the software development market. As such in this project, a testing strategy was
16
05/14/17
developed for JavaBeans with reference to testing Java programs in general. The simple Java class
symtbl was used to develop the testing strategy for Java programs in general and the bean form of
symtbl, the symtblBean, was used to extend the testing strategy to JavaBeans.
The testing methodology involved developing an informal document, called the test plan, which acts as
specification for testing. The implementation of the test plan was achieved in this case by using the
specification based testing tool Roast.
The testing strategy developed for the simple Java classes was extended to develop testing strategies
for JavaBeans component. JavaBeans components being reusable software component for the Java
platform. However, the difference between Java classes and JavaBeans created some interesting
problems, not all of which could be solved in this project due to the time restriction. Most of the
problems arise from the fact that JavaBeans contain events. Testing to see that a given event has fired
correctly required the greatest amount of changes to be made to the test plan and test implementation.
A listener bean is required to capture all of the events that are fired and allows the test driver to verify
that the event have indeed been fired correctly. The project was not able to get a listener been to
communicate properly with the bean under test. But once this bug is removed the testing strategy used
in this project should be able to be used on any non-GUI JavaBeans. As an extension to the work done
here testing strategies could be developed for GUI based JavaBeans.
Bibliography
1. Donovan Chris, “Testing Java Components” honours project, Department of Computer Science and
Electrical Engineering, The University of Queensland, 1999
2. Sun Microsystems, JavaBeans FAQ, http://java.sun.com/beans/FAQ/, 1999
3. Nigel D, Hoffman D and Strooper P, Unit Operations for Automated Class Testing, Technical
Report no. 00-04, Software Verification Research Centre, University of Queensland, 2000.
4. Hamilton G (Editor), JavaBeans API specification document, Sun Microsystems,
http://java.sun.com/products/javabeans/docs/beans.101.pdf, 1997.
17