Approach of Unit testing

with the help of JUnit

Unit Testing
 Testing concepts
 Unit testing
 Testing tools
 JUnit
 Practical use of tools
 Examples
 How to create JUnit TestCase in Eclipse

Unit testing with JUnit 2

Why?

 Why testing?
 Improve software design
 Make software easier to understand
 Reduce debugging time
 Catch integration errors
 In short, to Produce Better Code
 Preconditions
 Working code
 Good set of unit tests

Unit testing with JUnit 3

What should be tested ?

 Test for boundary conditions

 Test for both success and failure
 Test for general functionality
 Etc..

Unit testing with JUnit 4

When to start testing

Software quality and testing is a

life-cycle process

Unit testing with JUnit 5

When to start testing...

 At the time of starting the projects

 How we start the projects ??
 Do we have any formal way ??

Unit testing with JUnit 6

 The V-model of development

Requir ements System System Detailed

specification specification design design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test integration test

Unit testing with JUnit 7

Fact of testing

Testing does not guarantee

the absence of defects

Unit testing with JUnit 8

What is test case

 A test case is a document that describes an

input, action, or event and an expected
response, to determine if a feature of an
application is working correctly

Unit testing with JUnit 9

Good test case design
 An good test case satisfies the following
criteria:
 Reasonable probability of catching an error
 Does interesting things
 Doesn’t do unnecessary things
 Neither too simple nor too complex
 Not redundant with other tests
 Makes failures obvious
 Mutually Exclusive, Collectively Exhaustive
Unit testing with JUnit 10
Test case design technique
 Test case design techniques can be broadly
split into two main categories

 Black box (functional)

 White box (structural)

Unit testing with JUnit 11

Black Box tests

Input Output

 Targeted at the apparent simplicity of the software

 Makes assumptions about implementation
 Good for testing component interactions
 Tests the interfaces and behavior

Unit testing with JUnit 12

White Box tests

Input Output

 Targeted at the underlying complexity of the software

 Intimate knowledge of implementation
 Good for testing individual functions
 Tests the implementation and design
Unit testing with JUnit 13
Test case writing example

 Suppose we have two parameters we want to cover in a set of

tests. Parameters are as follows..

 Operating system  Printers

 Win98  HP 4100
 Win2k  HP 4200
 Winxp

How We should write test case for this ??

Unit testing with JUnit 14

Types of Tests

 Unit
 Individual classes or types

 Component
 Group of related classes or
types

 Integration
 Interaction between classes

Unit testing with JUnit 15

What is a testing framework?
 A test framework provides reusable test
functionality which:
 Is easier to use (e.g. don’t have to write the same
code for each class)
 Is standardized and reusable
 Provides a base for regression tests

Unit testing with JUnit 16

Why use a testing framework?
 Each class must be tested when it is
developed
 Each class needs a regression test
 Regression tests need to have standard
interfaces
 Thus, we can build the regression test when
building the class and have a better, more
stable product for less work

Unit testing with JUnit 17

Regression testing
 New code and changes to old code can
affect the rest of the code base
 ‘Affect’ sometimes means ‘break’
 We need to run tests on the old code, to
verify it works – these are regression tests
 Regression testing is required for a stable,
maintainable code base

Unit testing with JUnit 18

Testing tools

Tools are part of the quality

equation, but not the entire
equation

Unit testing with JUnit 19

JUnit
 JUnit is a framework for writing unit tests
 A unit test is a test of a single class
 A test case is a single test of a single method
 A test suite is a collection of test cases

 Unit testing is particularly important when

software requirements change frequently
 Code often has to be refactored to incorporate the
changes
 Unit testing helps ensure that the refactored code
continues to work
Unit testing with JUnit 20
JUnit..
 JUnit helps the programmer:
 Define and execute tests and test suites
 Formalize requirements and clarify architecture
 Write and debug code
 Integrate code and always be ready to release a
working version

Unit testing with JUnit 21

What JUnit does
 JUnit runs a suite of tests and reports results
 For each test in the test suite:
 JUnit calls setUp()
 This method should create any objects you may need
for testing

Unit testing with JUnit 22

What JUnit does…
 JUnit calls one test method
 The test method may comprise multiple test cases;
that is, it may make multiple calls to the method you
are testing
 In fact, since it’s your code, the test method can do
anything you want
 The setUp() method ensures you entered the test
method with a virgin set of objects; what you do with
them is up to you
 JUnit calls tearDown()
 This method should remove any objects you created

Unit testing with JUnit 23

Creating a test class in JUnit
 Define a subclass of TestCase
 Override the setUp() method to initialize object(s) under test.
 Override the tearDown() method to release object(s) under test.
 Define one or more public testXXX() methods that exercise the
object(s) under test and assert expected results.
 Define a static suite() factory method that creates a TestSuite
containing all the testXXX() methods of the TestCase.
 Optionally define a main() method that runs the TestCase in
batch mode.

Unit testing with JUnit 24

Fixtures
 A fixture is just a some code you want run before
every test
 You get a fixture by overriding the method
 protected void setUp() { …}

 The general rule for running a test is:

 protected void runTest() {
setUp(); <run the test> tearDown();
}
 so we can override setUp and/or tearDown, and
that code will be run prior to or after every test case
Unit testing with JUnit 25
Implementing setUp() method
 Override setUp() to initialize the variables,
and objects
 Since setUp() is your code, you can modify it
any way you like (such as creating new
objects in it)
 Reduces the duplication of code

Unit testing with JUnit 26

 Implementing the tearDown()
method
 In most cases, the tearDown() method
doesn’t need to do anything
 The next time you run setUp(), your objects will
be replaced, and the old objects will be available
for garbage collection
 Like the finally clause in a try-catch-finally
statement, tearDown() is where you would
release system resources (such as streams)

Unit testing with JUnit 27

The structure of a test method
 A test method doesn’t return a result
 If the tests run correctly, a test method does
nothing
 If a test fails, it throws an
AssertionFailedError
 The JUnit framework catches the error and
deals with it; you don’t have to do anything

Unit testing with JUnit 28

Test suites
 In practice, you want to run a group of related
tests (e.g. all the tests for a class)
 To do so, group your test methods in a class
which extends TestCase
 Running suites we will see in examples

Unit testing with JUnit 29

assertX methods
 static void assertTrue(boolean test)
 static void assertFalse(boolean test)
 assertEquals(expected, actual)
 This method is heavily overloaded: arg1 and arg2 must be both
objects or both of the same primitive type
 For objects, uses your equals method, if you have defined it
properly, as public boolean equals(Object o) --otherwise it
uses ==.
 assertSame(Object expected, Object actual)
 Asserts that two objects refer to the same object (using ==)

 assertNotSame(Object expected, Object actual)
 assertNull(Object object)
Unit testing with JUnit 30
assertX methods
 assertNotNull(Object object)
 fail()
 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 .

 All the above may take an optional String message as the

first argument, for example,
static void assertTrue(String message, boolean test)

Unit testing with JUnit 31

Organize The Tests
 Create test cases in the same package as the code
under test
 For each Java package in your application, define a
TestSuite class that contains all the tests for
validating the code in the package
 Define similar TestSuite classes that create higher-
level and lower-level test suites in the other
packages (and sub-packages) of the application
 Make sure your build process includes the
compilation of all tests

Unit testing with JUnit 32

 Testing client Test fTests

TestCase TestSuite

run(TestResult) run(TestResult)
TestResult
setUp() addTest(Test)
runTest()
tearDown()

forall test in fTests

setUp()
test.run(TestResult)
runTest()
tearDown()
ConcreteTestCase

setUp()
TestedClass runTest()
action()
tearDown()
test1()
test2()
JUnit
fName
framework
test1()
runTest() or
test2()
Unit testing with JUnit 33
Example: Counter class
 For the sake of example, 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

Unit testing with JUnit 34

Example: Counter class
 We write the test methods before we write
the code
 This has the advantages described earlier
 Depending on the JUnit tool we use, we may
have to create the class first, and we may have to
populate it with stubs (methods with empty
bodies)
 Don’t be alarmed if, in this simple example,
the JUnit tests are more code than the class
itself
Unit testing with JUnit 35
JUnit tests for Counter

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

Unit testing with JUnit 36

JUnit tests for Counter…

public void testIncrement() {

assertTrue(counter1.increment() == 1);
assertTrue(counter1.increment() == 2);
}
public void testDecrement() {
assertTrue(counter1.decrement() == -1);
}
} // End from last slide

Unit testing with JUnit 37

The Counter class itself
 public class Counter {
int count = 0;
public int increment() {
return ++count;
}
public int decrement() {
return --count;
}
 public int getCount() {
return count;
}
}

Unit testing with JUnit 38

TestCase lifecycle
1. setUp
2. testXXX()
3. tearDown()
4. Repeats 1 through 3 for each testXXX
method…

Unit testing with JUnit 39

Test Suites
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

import example.SimpleTest;
import example.HtmlDocumentTest; Demo

public class AllTests {

static public Test suite() {
TestSuite suite = new TestSuite();
suite.addTestSuite(SimpleTest.class);
suite.addTestSuite(HtmlDocumentTest.class);
return suite;
}
}
Unit testing with JUnit 40
JUnit Best Practices
 Separate production and test code
 But typically in the same packages
 Compile into separate trees, allowing deployment
without tests
 Don’t forget OO techniques, base classing
 Test-driven development
1. Write failing test first
2. Write enough code to pass
3. Refactor
4. Run tests again
5. Repeat until software meets goal
6. Write new code only when test is failing

Unit testing with JUnit 41

Why JUnit
 Allow you to write code faster while increasing
quality
 Elegantly simple
 Check their own results and provide immediate
feedback
 Tests is inexpensive
 Increase the stability of software
 Developer tests
 Written in Java
 Free
 Gives proper uniderstanding of unit testing
Unit testing with JUnit 42
Problems with unit testing
 JUnit is designed to call methods and
compare the results they return against
expected results
 This ignores:
 Programs that do work in response to GUI
commands
 Methods that are used primary to produce
output

Unit testing with JUnit 43

Problems with unit testing…
 Heavy use of JUnit encourages a “functional”
style, where most methods are called to
compute a value, rather than to have side
effects
 This can actually be a good thing
 Methods that just return results, without side
effects (such as printing), are simpler, more
general, and easier to reuse

Unit testing with JUnit 44

Eclipse GUI API and APlib API

Unit testing with JUnit 45

Traversal Highlighting View
 Extension point:
 org.eclipse.ui.views

 Class extends ViewPart

 Create widgets in the view by instantiating
the classes of those widgets.
 Only a StyledText is needed!

Unit testing with JUnit 46

handleCursorPositionChanged

In your Editor Class.

Override handleCursorPositionChanged
method to implement the update action, and
checking if cursor select a strategy or xpath.

Unit testing with JUnit 47

Get current Cursor Offset

ITextSelection selection =
(ITextSelection) yourEditor.
getSelectionProvider().
getSelection();

selection.getOffset());

Unit testing with JUnit 48

Implement your
IDocumentPartitioner
 org.eclipse.jface.text.IDocumentPartitioner

 public ITypedRegion[] computePartitioning(int offset,

int length)

 When document is changed, you need to recalculated

Unit testing with JUnit 49

StyledText
 org.eclipse.swt.custom.StyledText
 SWT widget
 append(String string)
 setStyleRanges(StyleRange[])
 StyleRange specifies various styles for
some parts of the text

Unit testing with JUnit 50

Construct DJ Class Graph
 Create a new class graph.
 Be sure to use: edu.neu.ccs.demeter.aplib.cd.ClassGraph
 ClassGraph.fromString(String s)
 Construct Traversal
 Traversal.getEdgeSets()
 Traversal.getNodeSets()
 Tricky part: Create ClassGraph from source files

Unit testing with JUnit 51