Unit Test Rept

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Unit Test Document for PIMS

1. Introduction
In this document, we give the test plan and test results for unit testing of some of the key
modules of the Personal Investment Management System (PIMS).

2.Unit Testing Methodology

2.1 Selection of units: We selected only the most important functional and critical classes
for formal unit testing. In the test environment we used, a unit for unit testing is a class.
Here we illustrate the testing methodology by discussing only two classes.

2.2 Test Scripts: As we used Junit for unit testing. The test scripts were java programs
and each test case corresponded to a method in these java programs.

2.3 Fixing of Defects: The programmer fixed the defects found. Unit testing was
successfully complete only if the script executed without any defects.

2.4 Test Script Enhancement: As testing proceeded, some new test cases were added.
This was done by adding new test methods to the testing program.

3. The Testing Tool: Junit


We used Junit as the tool for unit testing. It is open source software which can be used to
test Java modules. It can be freely downloaded from the website www.junit.org
The general way to test the module (usually a ‘class’) by Junit: We create a class
extending TestCase(a predefined class of Junit), and write the following methods:
(a) setUp(): In this we instantiate various objects needed to perform the testing.
(b) tearDown(): In this we deallocate all or some of the memory which was used
up by objects created in setUp() method. This is called at the end of all tests.
(c) suite(): This method is used to create a test suite, which specifies as to which
tests will be performed.
(d) Various methods of the name testXXX(): These methods contain the actual
code for testing. In any such method, we do whatever operations we want to
do, and then call the method assertTrue()/assertFalse(), with a boolean as the
argument, which specifies as to what condition we wish to hold true/false,
for being convinced that the tested method performs correctly.

4. Tests Performed
We unit tested the methods of following two classes: (a) Alerts, and (b) Investment

(a) Testing methods of class Alerts:

Operation performed Condition tested Actual result


Nil Number of alerts should be Test passed.

1
zero
Create a new alert, with a Retrieve the first alert. Its Test passed.
particular date and date and description should
particular description. match with the date and
description with which we
created the alert.
Delete the first alert. Number of alerts should be Test passed.
zero.

Create two new alerts, one Number of alerts should be Test passed.
with a past date and other two.
with a future date.
Retrieve for pending alerts. Number of alerts returned Test passed.
should be one.
Delete alert number 0 Number of alerts should be Test passed.
twice. zero.

(b) Testing the methods of class Investment for correct manipulation of portfolios and
securities

Operation performed Condition tested Actual result


Create a portfolio with Check that there exists a Test Passed.
name PF1 portfolio with name PF1
Create a bank type security Check that there exists a Test Passed
bankTest in PF1 security bankTest in
portfolio PF1.
Add three transactions, Retrieve all the Test Passed
with any attribtues. transactions, and check that
a particular transaction had
the same details as you
entered.
Delete security bankTest. Check that there is no Test Passed
security with name
bankTest in portfolio PF1
Add a security shareTest in Check that shareTest exists Test Passed
PF1 in PF1
Rename shareTest to Check that shareTest does Test Passed
shareTestNew. not exist in PF1 and
shareTestNew exists in PF1.
Delete shareTestNew Check that shareTest New Test Passed
does not exist in PF1.
Rename PF1 to PF2. Check that portfolio PF1 Test Passed
does not exist and PF2
exists.

2
Delete PF2 Check that PF2 does not Test Passed
exist.

Operation performed Condition tested Actual result


Create portfolio PF1 Check that PF1 exists Test Passed
Create security bankTest in Check that bankTest exists Test Passed
PF1 with rate of interest = in PF1
1%.
- Check that roi of bankTest Test Passed
is 1%
Add three transactions. Find out the networth of Test Passed
this bank security and
compare with correct value.
Delete bankTest Check that bankTest does Test Passed
not exist.
Add security shareTest Check that shareTest does Test Passed
not exist.
Add five transactions. Find networth and compare Test Passed
with correct value.
- Find roi and compare with Test Failed. A bug in roi
correct value. computation found and
fixed. Then test passed.
Delete shareTest. Check that shareTest does Test Passed
not exist in PF1.
Delete PF1 Check that PF1 does not Test Passed
exist.

5. Results:
When the script written (which is in fact a Java file) and compiled and run, it gives us
the number of tests actually executed, and also in how many of them expected results
were obtained, in how many expected results were not obtained, and how many tests
could not go to completion.

For first test suite (testing for Alert.java):


6 tests: success: 6, failure: 0, error: 0
For second test suite (first test suite for Investment.java)
9 tests: success: 9, failure: 0, error: 0
For third suite (second test suite for Investment.java)
10 tests: success:9, failure: 1, error:0
The failure was due to a bug in the ROI calculation; the bug was fixed.

You might also like