Transcript Software Testing and Quality Assurance

Software Testing and Quality
Assurance
Lecture 23 – JUnit Tutorial
1
Lecture Outline

Get familiar with a software testing tool
(JUnit).
2
Assert

Assert within a test:



Call the method being tested and get the
actual result.
assert what the correct result should be
with one of the provided assert methods.
These steps can be repeated as many
times as necessary.
3
JUnit assert methods

static void assertTrue(boolean test)
static void assertTrue(String message, boolean
test)
 Throws an AssertionFailedError if the test fails (the optional
message is included in the Error)

static void assertFalse(boolean test)
static void assertFalse(String message, boolean
test)
 Throws an AssertionFailedError if the test fails.

assertEquals(expected, actual)
assertEquals(String message, expected, actual)
 For objects, uses your equals method, if you have defined it
properly, as public boolean equals(Object o)--otherwise it
uses ==
4
JUnit assert methods
(cont...)

assertSame(Object expected, Object actual)
assertSame(String message, Object expected,
Object actual)


Asserts that two objects refer to the same object (using
==).
assertNotSame(Object expected,
Object actual)
assertNotSame(String message,
Object expected, Object actual)

Asserts that two objects do not refer to the same
object.
5
JUnit assert methods
(cont...)

assertNull(Object object)
assertNull(String message, Object object)
 Asserts that the object is null.

assertNotNull(Object object)
assertNotNull(String message, Object object)
 Asserts that the object is not null.

fail()
fail(String message)
 Causes the test to fail and throw an AssertionFailedError
 Useful as a result of a complex test, when the other assert
methods aren’t quite what you want.
6
When to use an assert
statement

Use assertTrue to document a
condition that you “know” to be true.

Use assertFalse; in code that you
“know” cannot be reached (such as a
default case in a switch statement).
7
Example: Counter class



We will create and test a trivial “counter” class:
 The constructor will create a counter and set it to
zero.
 The increment method will add one to the
counter and return the new value.
 The decrement method will subtract one from the
counter and return the new value.
We write the test methods before we write the code.
Don’t be alarmed if, in this simple example, the JUnit
tests are more code than the class itself.
8
Example: JUnit tests for Counter
class (cont...)
public class CounterTest extends junit.framework.TestCase {
Counter counter1;
public CounterTest() { }
// default constructor
protected void setUp() {
// creates a (simple) test fixture
counter1 = new Counter();
}
protected void tearDown() { } // no resources to release
public void testIncrement() {
assertTrue(counter1.increment() == 1);
assertTrue(counter1.increment() == 2);
}
public void testDecrement() {
assertTrue(counter1.decrement() == -1);
}
}
Note that each test
begins with a brand
new counter
This means you don’t
have to worry about
the order in which the
tests are run
9
Example: The Counter class itself
(cont...)
public class Counter {
int count = 0;
public int
increment() {
return ++count;
}
public int
decrement() {
return --count;
}
public int getCount()
{
return count;
}
}





Is JUnit testing overkill for
this little class?
The Extreme Programming
view is: If it isn’t tested,
assume it doesn’t work
You are not likely to have
many classes this trivial in a
real program, so writing
JUnit tests for those few
trivial classes is no big deal
Often even XP programmers
don’t bother writing tests for
simple getter methods such
as getCount()
We only used assertTrue
in this example, but there are
additional assert methods10
Test suites

Obviously you have to test your code to
get it working in the first place:


You can do ad hoc testing (running
whatever tests occur to you at the
moment).
You can build a test suite (a thorough set of
tests that can be run at any time).
11
Test suites: advantages and
disadvantages


Disadvantages of a test suite:
 It’s a lot of extra programming:
 This is true, but use of a good test framework
can help quite a bit.
 You don’t have time to do all that extra work:
 False--Experiments repeatedly show that test
suites reduce debugging time more than the
amount spent building the test suite.
Advantages of a test suite:
 Reduces total number of bugs in delivered code.
12
TestRunners: text

Text:
Lightweight, quick quiet.
 Run from command line.

java StringTest
.......
Time: 0.05
Tests run: 7,
Failures: 0,
Errors: 0
13
TestRunners: swing

Run with java junit.swingui.TestRunner.
14
Example: point class
public class Point {
private int x, y;
public Point(int x, int y){ this.x = x; this.y
= y;}
public void setX(int x) { this.x = x; }
public void setY(int y) { this.y = y; }
public int getX() { return x; }
public int getY() { return y; }
}
15
Example (cont...): point test without
using JUnit
public class PointTestNoJunit {
public static void main(String [] args) {
testSetX(new Point(10, 20), 0);
testSetX(new Point(10, 20), 1);
testSetX(new Point(10, 20), 30);
}
private static void testSetX(Point p, int x) {
System.out.print("Before: " + toString(p) +
";");
p.setX(x);
System.out.println(" After setX(" + x + "):
" +
toString(p));
}
private static String toString(Point p) {
return "<" + p.getX() + ", " + p.getY() +
">";
16
Example (cont...): point test without
using JUnit —output
Before: <10, 20>; After setX(0): <0, 20>
Before: <10, 20>; After setX(1): <1, 20>
Before: <10, 20>; After setX(30): <10, 20>
Before: <10, 20>; After setY(0): <10, 0>
Before: <10, 20>; After setY(1): <10, 1>
Before: <10, 20>; After setY(30): <10, 30>
17
Example (cont...): point test using
JUnit
import junit.framework.*;
/** A JUnit test class to test the class Point. */
public class PointTest extends TestCase {
/** Tests constructor. */
public void testPoint() {
Point p = new Point(10,20);
assertEquals(10, p.getX());
assertEquals(20, p.getY());
}
/** Tests setX */
public void testSetX() {
Point p = new Point(10, 20);
p.setX(30);
assertEquals(30, p.getX());
assertEquals(20, p.getY());
}
//other test methods, e.g., for setY(), getX(), and getY().
// cont…
18
Example (cont...): point test suite
using JUnit
/** Returns the test suite for this test class.
*/
public static Test suite() {
return new TestSuite(PointTest.class);
}
/** Run the tests. */
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
// junit.swingui.TestRunner.run(suite());
}
}
19
Example (cont...): point test using
JUnit —output
C:/> javac Point.java PointTest.java
C:/> java PointTest
...F.....
Time: 0.016
There was 1 failure:
testSetX1(PointTest)junit.framework.AssertionFailedError:
expected:<30> but was:<1>
at PointTest.testSetX1(PointTest.java:58)
…
at PointTest.main(PointTest.java:17)
FAILURES!!!
Tests run: 8, Failures: 1, Errors: 0
20
Example (cont...): point test using
JUnit —Test Fixture
public class PointTest extends TestCase {
private Point p; // test fixture variable
public void setUp() { // initializes text fixture
variables
p = new Point(10, 10);
}
public void tearDown() { }//clean up text fixture
variables
public void testSetX() { // tests SetX
p.setX(20);
assertEquals(20, p.getX());
}
public void testSetY() { // tests SetY
p.setY(30);
assertEquals(30, p.getY());
}
21
JUnit Testing Tips



Code a little, test a little, code a little, test a
little . . .
Run your tests as often as possible, at least
as often as you run the compiler.
Begin by writing tests for the areas of the
code that you’re the most worried about . .
.write tests that have the highest possible
return on your testing investment.
22
JUnit Testing tips





When you need to add new functionality to
the system, write the tests first.
If you find yourself debugging using
System.out.println(), write a test case instead.
When a bug is reported, write a test case to
expose the bug.
Don’t deliver code that doesn’t pass all the
tests.
Separate production and test code:

But typically in the same packages.
23