Approach of Unit testing with the help of JUnit

Unit Testing

Testing concepts

Unit testing

Testing tools

JUnit Examples

Practical use of tools

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

When to start testing

Software quality and testing is a life-cycle process

Unit testing with JUnit

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

The V-model of development

Requir ements specification System specification System design Detailed design

Acceptance test plan

System integration test plan

Sub-system integration test plan

Module and unit code and tess

Service

Acceptance test

System integration test

Sub-system integration test

Unit testing with JUnit

Fact of testing

Testing does not guarantee the absence of defects

Unit testing with JUnit

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

Good test case design

An good test case satisfies the following criteria:

Reasonable probability of catching an error Does interesting things Doesnt 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

Unit testing with JUnit 13

Tests the implementation and design

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 Win2k Winxp

HP 4100 HP 4200

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. dont 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 its 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 doesnt 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 doesnt 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 dont 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 ==. Asserts that two objects refer to the same object (using ==)

assertSame(Object expected, Object actual)

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 arent 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 higherlevel 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 run(TestResult) setUp() runTest() tearDown() TestResult

TestSuite run(TestResult) addTest(Test)

setUp() runTest() tearDown() ConcreteTestCase TestedClass action() setUp() runTest() tearDown() test1() test2() fName

forall test in fTests test.run(TestResult)

JUnit framework
test1() or test2() Unit testing with JUnit
33

runTest()

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)

Dont 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. 2. 3. 4.

setUp testXXX() tearDown() 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

1. 2. 3. 4. 5. 6.

Separate production and test code But typically in the same packages Compile into separate trees, allowing deployment without tests Dont forget OO techniques, base classing Test-driven development
Write failing test first Write enough code to pass Refactor Run tests again Repeat until software meets goal 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