Unit Testing and the JUnit Framework

1
Unit Testing and the J-Unit Framework

• CS4320
• Fall 2005

2
Two Key Concepts

• Validation Are we building the right thing?
  Conformance to customer requirements and quality
  attributes.
• Verification Are we building the thing right?
  Process conformance, quality activities.

3
Where does testing fit in?
PHASE O Testing Debugging
PHASE 1 Testing shows the software works
PHASE 2 Testing shows the software doesnt work
PHASE 3 Testing doesnt prove anything, it
reduces risk of unacceptable
software delivery.
PHASE 4 Testing is not an act, a mental
discipline of quality.
4
The Testing Quote
Testing cannot show the absence of defects, it
can only show that software defects are present.
We cannot test quality into a product, we have to
design it in.
5
Test Objectives

• Tests intended to find errors
• Good test cases have high p for finding a yet
  undiscovered error
• Successful tests cause program failure, i.e. find
  an undiscovered error.
• Minimal set of test cases needs to be developed
  because exhaustive testing not possible

6
Testing Phases

• Unit
• Integration
• Component
• System
• Usability
• Regression
• Validation
• Alpha/Beta (FUT/OT)

7
Types of testing

• Structural (Whitebox)
• Functional (Blackbox)
• Statistical (Random)
• Mutation
• Object Oriented (State-based)
• Insert latest PhD thesis topic here

8
Whitebox Testing

• AKA Structural, Basis Path Test
• Normally used at unit level
• Assumes errors at unit level are in the control
  structure or data path
• Generates test cases to test control paths
  through the code
• Criteria includes Control-Flow and Data-Flow
  based coverage

9
Coverage Criteria

• Control Flow based
• Statement Coverage (All nodes)
• Branch (or Decision) Coverage (All edges)
• All Paths
• Data Flow based
• All DU paths
• All C uses
• All Defs
• Etc

10
Example Program
int invoice (int x, int y) int d1, d2, s
if (xlt30) d2100 else d290 s5x 10
y if (slt200) d1100 else if (slt1000) d1
95 else d1 80 return
(sd1d2/10000)
11
Strength of Coverage
12
How effective?
Strategy Mean Cases Bugs Found Random Testing
100
79.5 Branch Testing 34
85.5 All Uses
84
90.0
13
Blackbox Testing

• AKA Specification-Based
• Uses functional requirements to derive test cases
• Assumes errors include missing or improperly
  implemented functions
• No knowledge of implementation details

14
Equivalence Partitioning

• Divide input domain into classes of data
• Single test case can cover all equivalent data
  elements
• Partitions consist of valid and invalid sets

15
Invoice Specification
Invoices are calculated using the following
algorithm based on quantity of x and y Item X
sells for 5 and Item Y sells for 10 Invoice
Total gt200 get 5 discount Invoice
Total gt1000 get 10 discount Invoices
that order more than 30 X items
get a 5 discount
16
Border/Boundary Conditions
Most errors happen at the boundary, so select
test cases that test at and on each side of the
boundary.
X Boundaries
30, 31, -1, 0
Y Boundaries
-1, 0
Invoice Total Boundaries 200, 199, 999,1000
If there are specification limits on data sizes
be sure to test at the limits i.e. program must
store up to 100 numbers, then test at 100. What
happens at 101???
17
What is xUnit?

• An automated unit test framework
• Provides the Driver for unit(s)
• Provides automatic test runs
• Provides automatic result checks
• Available for multiple languages
• cppUnit
• sUnit
• Junit

18
Junit Terms

• Failure Expected
• Error Unexpected (Exception)
• TestCase Collection of method tests
• Test Fixture Object Reuse for multiple tests
• TestSuite Collection of Test Cases
• TestRunner Interface
• awt, swing,text

19
Example, Complex Class
public class Complex int real_part int
imaginary_part public Complex(int r, int i)
real_partr imaginary_parti
public Complex() real_part0
imaginary_part0 public boolean
Equal(Complex c) boolean result false
if ((real_partc.get_r())
(imaginary_partc.get_i())) resulttrue
return result public Complex Add(Complex
c) Complex result new Complex(c.get_r()re
al_part,c.get_i()imaginary_part) return
result public int get_r() return
real_part public int get_i() return
imaginary_part
20
Using Junit (Create Fixture)

• public class ComplexTest extends TestCase
• Complex c1
• Complex c2
• protected void setUp()
• c1 new Complex(7,3)
• c2 new Complex(12,6)
• protected void tearDown()

21
Using Junit (Add Test Cases)

• public void testAdd()
• Complex result c1.Add(new Complex(5,3))
• assertEquals(result.get_r(),c2.get_r())
• assertEquals(result.get_i(),c2.get_i())
• public void testEqual()
• assertTrue(!c2.Equal(c1))
• assertTrue(c1.Equal(new Complex(7,3)))

assertNull, assertNotNull, assertSame
22
Using Junit (Make Suite)

• public static Test suite()
• TestSuite suite new TestSuite()
• //TestSuite suite new TestSuite(ComplexTest.clas
  s)
• suite.addTest(new ComplexTest(testAdd))
• suite.addTest(new ComplexTest(testEqual))
• return suite

23
Using Junit (Batch Invoke and Constructor)

• public static void main(String args)
• junit.textui.TestRunner.run(suite())
• public ComplexTest(String s)
• super(s)

24
The Graphical UI
25
UI on Failure
26
What Junit does not do

• Figure out your tests for you
• Calculate any coverage criteria
• Test GUIs
• Except extensions
• JFCUnit
• Jemmy
• Pounder
• Abbot

27
Administrative

• Download latest version (3.8.1) from
• www.junit.org
• Setup classpath to junit.jar
• Include appropriate ui in main
• Import junit.framework.