Unit Testing

Moamin Abughazala
Agenda
• Basic Testing
• Unit testing
• Junit with eclipse
• First test case
• Running Test
• Annotations
• Assertion
• Ignore
• Timeout
• Expected Exception
• Parametrized
• Test Suite
Basic Testing
• Software Reliability: Probability that a software system will not
cause failure under specified conditions.
• Bugs are inevitable in any complex software system.
• Industry estimates: 10-50 bugs per 1000 lines of code.
• A bug can be visible or can hide in your code until much later.
• Testing : A systematic attempt to reveal errors.
• Failed test: an error was demonstrated.
• Passed test: no error was found (for this particular situation).
 Why are software tests helpful?
• Software unit tests help the developer to
verify that the logic of a piece of the
program is correct.
• Running tests automatically helps to identify
software regressions introduced by
changes in the source code. Having a high
test coverage of your code allows you to
continue developing features without
having to perform lots of manual tests
 Unit testing
• Unit Test Case : is a part of code which ensures that the another
part of code (method) works as expected.(by developers)
• The percentage of code which is tested by unit tests is
typically called test coverage.
• To achieve those desired results quickly, test framework is required
.JUnit is perfect unit test framework for java programming language.
 Which part of the software should be
tested?
• should every statement in your code be
tested ???!!
• You should write software tests for the
critical and complex parts of your
application.
JUnit Features
1. JUnit is an open source framework
2. Provides Annotation to identify the test
methods.
3. Provides Assertions for testing expected
results.
4. Provides Test runners for running tests.
 JUnit and Eclipse
• To add JUnit to an Eclipse project, click:
• Project  Properties  Build Path 
Libraries 
Add Library...  JUnit  JUnit 4  Finish
• To create a test case:
• right-click a file and
choose New  Test Case
• or click File  New 
JUnit Test Case
JUnit - Writing test class
import org.junit.*;
import static org.junit.Assert.*;

public class ClassName {

...

@Test
public void name() { // a test case method
...
}
}
• A method with @Test is flagged as a JUnit test case.
• All @Test methods run when JUnit runs your test class.
 Running a test
• Right click it in the Eclipse Package Explorer at
left; choose:
Run As  JUnit Test
• The JUnit bar will show
• Green if all tests pass,
• Red if any fail.
• The Failure Trace shows which tests
failed, if any, and why
Annotation Description

More JUnit annotations

@Test 
@Test (expected =
The @Test annotation identifies a method as a test method.
Fails if the method does not throw the named exception.
Exception.class)
@Test(timeout=100) Fails if the method takes longer than 100 milliseconds.
@Before This method is executed before each test. It is used to prepare
the test environment (e.g., read input data, initialize the class).
@After  This method is executed after each test. It is used to cleanup
the test environment (e.g., delete temporary data, restore
defaults). It can also save memory by cleaning up expensive
memory structures.
@BeforeClass  This method is executed once, before the start of all tests. It is
used to perform time intensive activities, for example, to
connect to a database. Methods marked with this annotation
need to be defined as static to work with JUnit.
@AfterClass  This method is executed once, after all tests have been
finished. It is used to perform clean-up activities, for example,
to disconnect from a database. Methods annotated with this
annotation need to be defined as static to work with JUnit.
@Ignore or Ignores the test method. This is useful when the underlying
@Ignore("Why code has been changed and the test case has not yet been
disabled") adapted. Or if the execution time of this test is too long to be
included. It is best practice to provide the optional description,
why the test is disabled.
JUnit assertion methods
assertTrue(test) fails if the boolean test is false

assertFalse(test) fails if the boolean test is true

assertEquals(expected, actual) fails if the values are not equal

assertSame(expected, actual) fails if the values are not the same (by ==)

assertNotSame(expected, actual) fails if the values are the same (by ==)

assertNull(value) fails if the given value is not null

assertNotNull(value) fails if the given value is null

fail() causes current test to immediately fail

• Each method can also be passed a string to display if it fails:

e.g. assertEquals("message", expected, actual)

• Why is there no pass method?

Ex : ArrayIntList JUnit test
import org.junit.*;
import static org.junit.Assert.*;
public class TestArrayIntList {
@Test
public void testAddGet1() {
ArrayList<String> list = new
ArrayIntList<String>();
list.add(“An Najah”);
list.add(”National”);
list.add(“University”);
assertEquals((“An Najah”, ls.remove(0));
assertEquals(”National”, ls.remove(0));
assertEquals(“University”, ls.remove(0));
}
@Test
public void testIsEmpty() {
ArrayList<String> list = new ArrayIntList<String> ();
assertTrue(list.isEmpty());
list.add(123);
assertFalse(list.isEmpty());
list.remove(0);
assertTrue(list.isEmpty());
}
 Ignore Test
• Sometimes it happens that our code is not
ready and test case written to test that
method/code will fail if run. The @Ignore
annotation helps in this regards.
• A test method annotated with @Ignore will not be
executed.
• If a test class is annotated with @Ignore then
none of its test methods will be executed.
 Tests with a timeout
• @Test(timeout = 5000)
public void name() { ... }
• The above method will be considered a
failure if it doesn't finish running within 5000
ms
private static final int TIMEOUT = 2000;
...

@Test(timeout = TIMEOUT)
public void name() { ... }

• Times out / fails after 2000 ms

 Test execution order
• As of JUnit 4.11 the default which may vary from run to
run.t is to use a deterministic, but not predictable, order
for the execution of the tests
• You can use an annotation to define that the test methods
are sorted by method name.
• To activate this feature, annotate your test class with the
•  @FixMethodOrder(MethodSorters.NAME_ASCENDING) annotatio
n.
Expected Exceptions
• Junit provides a option of tracing the
Exception handling of code. You can test the
code whether code throws desired exception
or not. The expected parameter is used
along with @Test annotation.
• @Test(expected = Exception.class)
public void testPrintMessage() {}
 Parameterized tests
• Parameterized tests allow developer to run
the same test over and over again using
different values.
 Steps for Param. test
• There are five steps, that you need to follow to
create Parameterized tests.
• Annotate test class with
@RunWith(Parameterized.class)
• Create a public static method annotated with
@Parameters that returns a Collection of Objects
(as Array) as test data set.
• Create a public constructor that takes in what is
equivalent to one "row" of test data.
• Create an instance variable for each "column" of
test data.
• Create your tests case(s) using the instance
variables as the source of the test data.
 Test suites
• Test suite means bundle a few unit test
cases and run it together. In JUnit, both
@RunWith and @Suite annotation are used to
run the suite test.
Software Testing
Agenda

• Software Testing - Definition

• Testing Objectives
• Levels of Software Testing
• Testing Strategies
Definitions
• Testing :
• Testing is the process of executing a program with intention of finding
errors.
• IEEE definition:
1. The process of operating a system or component under specified
condition, observing or recording the results, and making an
evaluation of some aspect of the system or component.
2. The process of analyzing a software item to detect the difference
between the existing and required conditions ( that is, bugs ) and
evaluate the features of the software item.

23
Software testing - Definition
• Is a formal process carried out by specialized testing team
in which a software unit, several integrated software units or
entire software package are examined by running the
programs on a computer. All the associated tests are
performed according to approved test procedures on
approved test case.

24
Software testing objectives
• Direct objectives:
• To identify and reveal as many errors as possible in the tested SW.
• To bring the tested SW, after correction of the identified errors and
retesting, to an acceptable level of quality.
• To perform the required tests efficiently and effectively, within the limits
budgetary and scheduling limitation
• Indirect objectives
• To compile a record of SW errors for use in error prevention ( by
corrective & preventive actions )

25
 Who Does Testing ?
1. Software Tester
2. Software Developer – Unit Testing
3. Project Lead / Manager
4. End User
It depends on the process and the associated stakeholders of the
project(s)
When to Start Testing?
• An early start to testing reduces the cost and time to rework and
produce error-free software that is delivered to the client.
• Testing can be started from the Requirements Gathering phase and
continued till the deployment of the software.
• It also depends on the development model that is being used.
• For example, in the Waterfall model, formal testing is conducted in the testing phase;
• The incremental model, testing is performed at the end of every increment/iteration and
the whole application is tested at the end.
When to Stop Testing?
• It is difficult to determine when to stop testing, as testing is a never-
ending process and no one can claim that a software is 100% tested.
• The following aspects are to be considered for stopping the testing
process : 4
• Testing Deadlines
• Completion of test case execution.
• Bug rate falls below a certain level and no high-priority bugs are identified
• Management decision
Levels of Software Testing

• Unit testing
• Integration testing
• System testing
• Acceptance testing
Unit Testing
• Unit testing is a way of testing the smallest piece of code referred to
as a unit that can be logically isolated in a system. It is mainly focused
on the functional correctness of standalone modules.
• It is the micro level of testing
• It involves testing individual modules or units to make sure they're
working properly
• Unit testing
1. Unit tests improve the quality of your code
2. Find Software Bugs Early
3. Reduces Testing Costs
• What are the other Benefits of Unit Testing??!
Integration testing
• After Unit testing we have Integration testing
• this level tell how units work together
• Individual module are combined and tested as a group, it's one thing
if units walk well on their own but how do they perform together when
combined
• Integration testing :
1. helps you determine that and ensure your application runs efficiently
2. Identifies interface issues between modules
The Need for Integration testing
• A module/unit is usually designed by an individual software developer
whose techniques and programming logic differs from that of other
programmers
• Often at the time of module development, user requirements change
and these new requirements may not be unit tested.
• Issues like data formatting, hardware interfaces, and third-party
service interfaces are sometimes missed during unit testing
 System Testing
• All components of the software are tested as whole in order to ensure
that overall product meets the requirements which are specified.
• It is performed on the entire system in the context of either functional
requirement specifications (FRS) or system requirement specification
(SRS), or both. System testing tests not only the design, but also the
behavior and even the believed expectations of the customer.
• System Testing :
• it verifies technical, functional, and business requirements of the software or an
application
• It is usually done by testing team and it includes a combination of automation
testing as well as manual testing techniques.
Acceptance testing
• the final level of testing is acceptance testing or basically we call it
UAT (User Acceptance testing)
• It determines whether or not the software product is ready to be
released to market
• the functionality or functional requirements met or performance
requirement met or not
• UAT is the final say as to whether the application is ready for the use
in real life or not
Software Testing II
Software testing Strategies
• Incremental testing
• Bottom-Up Testing
• Top-Down Testing

• Big Bang testing

Big Bang testing
To test the Software as an entirely, meaning is, once the completed
package is available
Big Bang Integration Testing is an integration testing strategy wherein
all units are linked at once, resulting in a complete system
In this testing approach, once all the modules are developed and
tested individually, they are integrated once and tested together at
once.
In this type of integration testing all the components as well as the
modules of the software are integrated simultaneously, after which
everything is tested as a whole.
it is very much suitable for smaller systems.
37
Advantages and Disadvantages
• Adv
1. This testing technique prevents wastage of extra efforts and time, and
makes the testing process cost effective.
2. There is no need of immediate builds and efforts required for the system.
• Dis.
• If any bug is found it becomes difficult to detach(‫ )ف???صل‬all the modules on
order to find out its root cause.
• Since all the modules are tested together chances of failure increases.
• Error correction estimation of the required testing resources and testing
schedule a rather fuzzy endeavor‫ مسعىغ?امض‬.
Incremental testing
1. It is performed by connecting two or more modules together that
are logically related.
2. Later more modules are added and tested for proper functionality.
3. This is done until all the modules are integrated and tested
successfully.

• Performed according to 2 basic strategies:

• Bottom-up
• Top-down
Stubs & Drivers
• While testing, sometimes we face a situation where some of the
modules are still under development. These modules for testing
purpose are replaced with some dummy programs. These dummy
programs are called stubs and drivers.
Stubs
• Stubs ( often termed a “Dummy Module “ )replaces an unavailable
lower level module, subordinate to the module tested.
• It is required for top-down testing of incomplete systems.
Drivers
• A driver is a substitute module but of the upper level module that
activates the module tested.
• The driver is passing the test data on to the tested module and
accepting the results calculated by it.
• It is required in bottom-up testing until the upper level modules are
developed.
Top-down Testing
• The 1st module tested is the main module which is the highest
level module in the software structure and the last module to be
tested are the lowest level modules.

• Top-down integration testing is an integration testing technique

used in order to simulate the behavior of the lower-level modules
that are not yet integrated. Stubs are the modules that act as
temporary replacement for a called module and give the same
output as that of the actual product.
Top-down Testing

45
Bottom-up Testing
• The order of testing is reversed: the lowest level module are tested
first with the main module will be tested last.

• Each component at lower hierarchy is tested individually and then

the components that rely upon these components are tested.
Bottom-up Testing
Incremental testing Advantages
• Usually performed on relatively small SW modules, as unit
or integration tests.

• Identification and correction of errors is much simpler and

requires fewer resources because it is performed on a
limited volume of SW.

48
Software testing classification - code visible
level
• Black box ( functionality ) testing:
• Identifies bugs only according to SW malfunctioning as
they are revealed in its erroneous output.
• Incases that outputs are found to be correct, black box
testing disregarded the internal path of calculations and
processing performed.
• White box ( structural ) testing:
• Examines internal calculation paths in order to identify
bugs.

49
White box and black box testing for the various
classes of tests

50
White Box Testing
• White box testing is testing of a software solution's internal structure,
design, and coding.
• the code is visible. It focuses primarily on verifying the flow of inputs
and outputs through the application, improving design and usability,
strengthening security
• White box testing is also known as Clear Box testing, Open Box testing,
Structural testing, Transparent Box testing, Code-Based testing, and
Glass Box testing.
• It is usually performed by developers.

51
What do you verify in White Box Testing?
• White box testing involves
1. Internal security holes
2. poorly structured paths in the coding processes
3. The flow of specific inputs through the code
4. Expected output
5. The functionality of conditional loops
6. Testing of each statement, object, and function on an individual basis

• The testing can be done at integration & unit levels of software

development
White Box Testing Tools
1. Parasoft Jtest
2. EclEmma
3. NUnit
4. PyUnit
5. HTMLUnit
6. CppUnit
7. Junit
White Box Testing Techniques
• A major White box testing technique is Code Coverage analysis. Code Coverage
analysis eliminates gaps in a Test Case suite. It identifies areas of a program that
are not exercised by a set of test cases. Once gaps are identified, you create test
cases to verify untested parts of the code, thereby increasing the quality of the
software product.
• Code Coverage Techniques:
• Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests. (typical coverage is 80 – 90 %)
• Branch Coverage - This technique is running a series of tests to ensure that
all branches are tested at least once.(Decision coverage and it covers both the
true and false conditions)
• Path Coverage - This technique corresponds to testing all possible paths
which means that each statement and branch is covered.
Example 1
• if (x>y)
• PRINT x is greater than y

• So the Test Set for 100% branch coverage will be:

• Test Case 1: x=5, y=2 which will return true.
• Test Case 2: x=2, y=5 which will return false.
• Both the test cases 1 and 2 are required for Branch coverage.
• With only Test cases1, it will be statement coverage.
Flow Chart
 Statements Coverage
1. PrintSum(int a, int b) 1. Coverage measure = Number of
2. { executed statements / total number
of statements
3. int result = a+ b;
4. if(result > 0 )
2. List of test cases :
5. println(“Red Result”+ result); 1. TC#1 : a=3 , b=9 , coverage = 6/8
6. else if(result < 0) 2. TC#2 : a=-5, b=-8 , 7/8
7. println(“Blue Result”+ result); 3. With TC#1 & TC#2, we achieve
8. } 100% coverage
 1. Coverage measure = Number of
Branch Coverage executed branches / total number of
branches
1. PrintSum(int a, int b)
2. {
2. List of test cases :
3. int result = a+ b;
1. TC#1 : a=3 , b=9 , coverage = 1/4
4. if(result > 0 ) 2. TC#2 : a=-5, b=-8 , coverage = 2/4
5. println(“Red Result”+ result); 3. TC#3 : a=0 , b=0, coverage = 2/4

6. else if(result < 0)

7. println(“Blue Result”+ result);
8. }
Path Coverage
• Path 1: 1,2,3,5,6, 7
• Path 2: 1,2,4,5,6, 7
• Path 3: 1, 6, 7
Advantages & Dis. of White Box Testing
• Adv.
1. Code optimization by finding hidden errors.
2. White box tests cases can be easily automated.
3. Testing is more thorough as all code paths are usually covered.
4. Testing can start early in SDLC even if GUI is not available.

• Dis.
• White box testing is too much time consuming when it comes to large-scale programming
applications.
• White box testing is much expensive and complex.
• It can lead to production error because it is not detailed by the developers.
• White box testing needs professional programmers
Black box testing
• It is a testing technique in which functionality of the Application Under Test
(AUT) is tested without looking at the internal code structure, implementation
details and knowledge of internal paths of the software.
• This type of testing is based entirely on software requirements and
specifications. In Black Box Testing we just focus on inputs and output of the
software system without bothering about internal knowledge of the software
program.

• The testing can be done at Acceptance & System levels of software development

61
Types of Black Box Testing
• Functional testing - This black box testing type is related to the
functional requirements of a system;
• Non-functional testing - This type of black box testing is not related to
testing of specific functionality, but non-functional requirements such
as performance, scalability, usability.
Advantages and Dis. of black box testing
• Advantages
• Allows carrying out the majority of testing classes, such as load tests and availability tests
• Requires fewer resources than those required for white box testing
• Disadvantages
• Absence of control of line coverage.
• Impossibility of testing the quality of coding and its strict adherence to the coding standards.

63