Index of /~billard/se/cs4320/ex12
Name Last modified Size Description
![[DIR]](/icons/back.gif)
Parent Directory 20-Apr-2008 08:49 -
![[ ]](/icons/unknown.gif)
AllTests.class 19-May-2009 09:03 1k
![[TXT]](/icons/text.gif)
AllTests.java 19-May-2009 09:03 1k
DataBase.class 19-May-2009 09:03 2k
DataBase.java 19-May-2009 09:03 1k
Driver.class 19-May-2009 09:03 1k
Driver.java 19-May-2009 09:03 1k
GUI.class 19-May-2009 09:03 1k
GUI.java 19-May-2009 09:03 1k
Report.class 19-May-2009 09:03 1k
Report.java 19-May-2009 09:03 1k
print.bat 19-May-2009 09:03 1k
setpaths 19-May-2009 09:03 1k
sources.txt 19-May-2009 09:03 2k
temp 19-May-2009 09:03 1k
CS 4320 Software Testing and QA: Ex12 INTEGRATION TEST
======================================================
Platform: UNIX
Given: partial Java source code for a database application
Goal: perform integration test with driver/stubs using JUnit
See Exercise 11 for an introduction to JUnit test.
I. REQUIREMENTS
Build an application with a GUI that prompts for the table name in a
database, the primary key for a particular row, and which fields to
display. The application queries the database and displays the fields
from the row selected based on the primary key.
II. ANALYSIS
A) Database
Table: S
+------+-------+--------+--------+
| S_NO | SNAME | STATUS | CITY |
+------+-------+--------+--------+
| S1 | Smith | 20 | London |
| S2 | Jones | 10 | Paris |
| S3 | Blake | 30 | Paris |
| S4 | Clark | 20 | London |
| S5 | Adams | 30 | Athens |
+------+-------+--------+--------+
B) GUI
+--------------------------------+
| Application |
+--------------------------------+
| Key : S2 |
| Fields: SNAME CITY |
| Table : S |
+--------------------------------+
C) REPORT
SNAME: Jones CITY: Paris
III. DESIGN
A) Preliminary Design: UML Class Diagram
+------------------+
| TestCase |
+------------------+
| run() |
+------------------+
^
| is a
+------------------+ * has many +------------------+
| Driver |<------------| TestSuite |
has a +------------------+ +------------------+
+------------| testApplication()|-----------+ | run() |
| +------------------+ | +------------------+
| | |
v v v
+------------------+ +------------------+ +------------------+
| GUI | | Report | | DataBase |
+------------------+ +------------------+ +------------------+
| getKey() | | formQuery() | | executeQuery() |
| getFields() | | generateReport() | | |
| getTable() | | | | |
| displayReport() | | | | |
+------------------+ +------------------+ +------------------+
B) Detailed Design: UML Sequence Diagram
:Driver gui:GUI rpt:Report db:DataBase
------- ------- ---------- -----------
testApplication() | | | |
---------------------->| getKey() | | |
|--------------->| | |
| getFields() | | |
|--------------->| | |
| getTable() | | |
|--------------->| | |
| | formQuery() | |
|-------------------------------->| |
| | | executeQuery() |
|------------------------------------------------->|
| |generateReport()| |
|-------------------------------->| |
| displayReport()| | |
|--------------->| | |
| | | |
To understand the above diagrams, here is a lecture on UML:
http://www.sci.csueastbay.edu/~billard/cs4311/node3.html
The key points in the Class Diagram:
Driver extends (is a) TestCase
TestSuite has many (Vector) references to Drivers
Driver has a Java handle (reference) to a GUI, Report, DataBase object
The key points in the Sequence Diagram:
Driver has a testApplication method, which calls gui.getKey(); ...; gui.displayReport();
In all, it makes 7 object-oriented calls.
IV. IMPLEMENTATION
Completed: DataBase.java, Report.java
Partially Complete: GUI.java
% more *.java
V. INTEGRATION TEST
Use JUnit to control the interaction between objects. Note that JUnit is designed
to do unit test and not long interactions/assertions between objects. In this exercise,
we are pushing JUnit beyond it's intentions. Note that JUnit will only report the FIRST
exception in our test, and no others (unless the first exception is remedied).
Completed: AllTests.java
Partially Complete: Driver.java
A) Code testApplication() in Driver.java based on the Sequence Diagram.
% source setpaths
% javac *.java
% java AllTests
B) Use JUnit's assertTrue(String,boolean) to verify the returned results from the methods:
1. key.length() : 1..15
2. fields.length : 1..3
3. table.length(): 1..10
4. query.length(): >= 25
5. try {
// executeQuery
} catch (Exception e) {
assertTrue(e.getMessage(),false);
}
6. line.length() : > 0
% javac *.java
% java AllTests
Given the current implementation, some failures might arise (but only the FIRST is
reported by JUnit).
C) Code as a stub to match the GUI in the Analysis, part II.B:
getKey(), getFields(), getTable(), displayReport() [use System.out.println()]
This means that you are NOT really building a GUI, but a "stub" which acts
as a substitute. We use a stub because:
1. the real code is NOT available but we want to test other code
2. the real code IS available, but has not been unit tested. It could create
faults, which might be difficult to isolate.
The first three methods should be hard-coded (typical of stubs) to match
the data presented in part II.B. The displayReport is just a println of the String
(which by this time, is the "report").
% javac *.java
% java AllTests
Verify that no failures/errors occur and output corresponds to the Analysis, part II.C:
SNAME: Jones CITY: Paris
% java AllTests >results.txt
ONLINE students: submit
GUI.java
Driver.java
results.txt
VI. PROJECT NOTEBOOK (see print.bat):
README
AllTests.java
Driver.java
GUI.java
Report.java
DataBase.java
results.txt