Unit Testing and the J-Unit Framework

CS4320

Fall 2003

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.

Where does testing fit in?

PHASE O: Testing == Debugging

PHASE 1: Testing shows the software works

PHASE 2: Testing shows the software doesn’t work

PHASE 3: Testing doesn’t prove anything, it reduces risk of unacceptable software delivery.

PHASE 4: Testing is not an act, a mental discipline of quality.

“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.

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

Testing Phases

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

Types of testing

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

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

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…

Example Program

int invoice (int x, int y) { int d1, d2, s; if (x<=30) d2=100; else d2=90; s=5*x + 10 *y; if (s<=200) d1=100; else if (s<=1000) d1 = 95; else d1 = 80; return (s*d1*d2/10000);}

if

d2=100 d2=90

if

d1=100

if

d1=95

d1=80

return

x>30

s>200

s>1000

Strength of CoverageAll Paths

All du Paths

All u

All c some p

All d

All p some c

All p

Branch

Statement

How effective?

Strategy Mean Cases Bugs FoundRandom Testing 100 79.5Branch Testing 34 85.5All Uses 84 90.0

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

F(x)x Result

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

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 $10Invoice Total >=$200 get 5% discount

Invoice Total >=$1000 get 10% discount Invoices that order more than 30 X items get a 5% discount

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???

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– …

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

Example, Complex Class

public class Complex { int real_part; int imaginary_part; public Complex(int r, int i) { real_part=r; imaginary_part=i; } public Complex() { real_part=0; imaginary_part=0; } public boolean Equal(Complex c) { boolean result = false; if ((real_part==c.get_r()) && (imaginary_part==c.get_i())) result=true; return result; } public Complex Add(Complex c) { Complex result = new Complex(c.get_r()+real_part,c.get_i()+imaginary_part); return result; } public int get_r() { return real_part;} public int get_i() { return imaginary_part; }}

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(){

}}

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

Using Junit (Make Suite)

public static Test suite() {

TestSuite suite = new TestSuite();

suite.addTest(new ComplexTest(“testAdd”));

suite.addTest(new ComplexTest(“testEqual”));

return suite;

}

Using Junit (Batch Invoke and Constructor)

public static void main(String[] args) {

junit.textui.TestRunner.run(suite());

}

public ComplexTest(String s) {

super(s);

}

The Graphical UI

UI on Failure

What Junit does not do:

Figure out your tests for you Calculate any coverage criteria Test GUI’s

– Except extensions: JFCUnit Jemmy Pounder Abbot

Administrative

Download latest version (3.8.1) from:

www.junit.org Setup classpath to junit.jar Include appropriate ui in main Import junit.framework.*

Next Time

Extreme Programming!!!