Software Testing

UNIT TESTING
and testing frame work IN SOFTWARE
ENGINEERING

1
Unit testing

2
Concept of Unit Testing

3
Static Unit Testing

4
 Static Unit Testing (Code Review)
• Step 1: Readiness
– Criteria
• Completeness
• Minimal functionality
• Readability
• Complexity
• Requirements and design

documents
– Roles
• Moderator
• Author
• Presenter
• Record keeper
• Reviewers
• Observer
• Step 2: Preparation
– List of questions
– Potential Change Request (CR)
– Suggested improvement opportunities Figure 3.1: Steps in the code review process
5
 Static Unit Testing (Code Review)
• Step 3: Examination A Change Request (CR) includes the
– The author makes a presentation following details:
– The presenter reads the code – Give a brief description of the issue
– The record keeper documents the CR – Assign a priority level (major or
minor) to a CR
– Moderator ensures the review is on
track – Assign a person to follow it up
• Step 4: Re-work – Set a deadline for addressing a CR
– Make the list of all the CRs
– Make a list of improvements
– Record the minutes meeting
– Author works on the CRs to fix the
issue
• Step 5: Validation
– CRs are independently validated
• Step 6: Exit
– A summary report of the meeting
minutes is distributes

6
 Static Unit Testing (Code Review)

The following metrics can be collected from a code review:

• The number of lines of code (LOC) reviewed per hour

• The number of CRs generated per thousand lines of code (KLOC)
• The number of CRs generated per hour
• The total number of hours spend on code review process

7
 Static Unit Testing (Code Review)
• The code review methodology can be applicable to review other documents
• Five different types of system documents are generated by engineering department
– Requirement
– Functional Specification
– High-level Design
– Low-level Design
– code
• In addition installation, user, and trouble shooting guides are developed by
technical documentation group

Table 3.1: System documents

8
DYNAMIC TESTING

9
10
 Dynamic Unit Testing
• The environment of a unit is emulated and tested in isolation
• The caller unit is known as test driver
– A test driver is a program that invokes the unit under test (UUT)
– It provides input data to unit under test and report the test result
• The emulation of the units called by the UUT are called stubs
– It is a dummy program
• The test driver and the stubs are together called scaffolding
• The low-level design document provides guidance for selection of input test data

Figure 3.2: Dynamic unit test environment

11
 Dynamic Unit Testing
Selection of test data is broadly based on the following techniques:
• Control flow testing
– Draw a control flow graph (CFG) from a program unit
– Select a few control flow testing criteria
– Identify a path in the CFG to satisfy the selection criteria
– Derive the path predicate expression from the selection paths
– By solving the path predicate expression for a path, one can generate the data
• Data flow testing
– Draw a data flow graph (DFG) from a program unit and then follow the
procedure described in control flow testing.
• Domain testing
– Domain errors are defined and then test data are selected to catch those faults
• Functional program testing
– Input/output domains are defined to compute the input values that will cause
the unit to produce expected output values
12
13
14
15
16
 JUnit – A Framework for Unit Testing
• JUnit provides a basic class called TestCase.
• The tester
– Extends the TestCase class for each test case. 10 extensions for 10 test
cases.
– Alternatively, extend TestCase to have 10 methods for 10 test cases.
• The TestCase class provides methods to make assertions.
– assertTrue(Boolean condition)
– assertFalse(Boolean condition)
– assertEquals(Object expected, Object actual)
– assertEquals(int expected, int actual)
– assertEquals(double expected, double actual, double tolerance)
– assertSame(Object expected, Object actual)
– assertNull(Object testobject)
– …
• The tester can have her own assertions.
17
 JUnit – A Framework for Unit Testing
• Each assertion accepts an optional first parameter of type String; if
the assertion fails, the string is displayed.  Help for the tester…
• The assertEquals() method displays a message upon failure.
• junit.framework.AssertionFailedError: expected: <x> but
was: <y>
• Note that only failed tests are reported.
• The following shows how assertTrue() works.

static public void assertTrue(Boolean condition) {

if (!condition)
throw new AssertionFailedError();
}

Figure 3.5: The assertTrue() assertion throws an exception

18
 JUnit – A Framework for Unit Testing
import TestMe; // TestMe is the class whose methods are going to be tested.
import junit.framework.*; // This contains the TestCase class.

public class MyTestSuite extends TestCase { // Create a subclass of TestCase

public void MyTest1() { // This method is the first test case

TestMe object1 = new TestMe( ... ); // Create an instance of TestMe with
desired params
int x = object1.Method1(...); // invoke Method1 on object1
assertEquals(365, x); // 365 and x are expected and actual values,
respectively.
}

public void MyTest2() { // This method is the second test case

TestMe object2 = new TestMe( ... ); // Create another instance of
// TestMe with desired parameters
double y = object2.Method2(...); // invoke Method2 on object2
assertEquals(2.99, y, 0.0001d); // 2.99 is the expected value;
// y is the actual value;
// 0.0001 is tolerance level
}
}

Figure 3.5: An example test suite

19
 Tools For Unit Testing
• Code auditor
– This tool is used to check the quality of the software to ensure that it meets
some minimum coding standard
• Bound checker
– This tool can check for accidental writes into the instruction areas of memory,
or to other memory location outside the data storage area of the application
• Documenters
– These tools read the source code and automatically generate descriptions and
caller/callee tree diagram or data model from the source code
• Interactive debuggers
– These tools assist software developers in implementing different debugging
techniques
Examples: Breakpoint and Omniscient debuggers
• In-circuit emulators
– It provides a high-speed Ethernet connection between a host debugger and a
target microprocessor, enabling developers to perform source-level debugging
20
 Tools for Unit Testing
• Memory leak detectors
– These tools test the allocation of memory to an application which request for memory
and fail to de-allocate memory
• Static code (path) analyzer
– These tool identify paths to test based on the structure of code such as McCabe’s
cyclomatic complexity measure

Table 3.3: McCabe complexity

measure

21
 Tools for Unit Testing
• Software inspection support
– Tools can help schedule group inspection
• Test coverage analyzer
– These tools measure internal test coverage, often expressed in terms of control
structure of the test object, and report the coverage metric
• Test data generator
– These tools assist programmers in selecting test data that cause program to
behave in a desired manner
• Test harness
– This class of tools support the execution of dynamic unit tests
• Performance monitors
– The timing characteristics of the software components be monitored and
evaluate by these tools
• Network analyzers
– These tools have the ability to analyze the traffic and identify problem areas
22
 Tools for Unit Testing
• Simulators and emulators
– These tools are used to replace the real software and hardware that are not
currently available. Both the kinds of tools are used for training, safety, and
economy purpose
• Traffic generators
– These produces streams of transactions or data packets.
• Version control
– A version control system provides functionalities to store a sequence of
revisions of the software and associated information files under development

23
 Pytest
Pytest is a popular testing framework in Python, widely used for
writing small, scalable unit tests. In software engineering, it is
particularly useful because of its simplicity, flexibility, and powerful
features like automatic test discovery, support for fixtures,
parameterization.
1. Simple and easy to use
2.TestDiscovery: Automatically finds tests based on naming conventions
3.Assertions: Provides detailed error reports when an assertion fails.
4.Fixtures: Reusable setup and teardown functions to manage test dependencies.
5.Parameterization: Allows running a test with different sets of inputs and expected
outcomes

24
Software Testing Theory and Practice (Chapter 1: Basic Concepts and Preliminaries) © Naik & Tripathy
Unit Testing a Python Function
Suppose you have a simple function that calculates the factorial of
a number.
# factorial.py
def factorial(n):
if n < 0:
raise ValueError("Input must be a non-negative integer.")
elif n == 0 or n == 1:
return 1
else:
result = 1
for i in range(2, n + 1):
result *= i
return result

25
 Writing Unit Tests with pytest
You can write unit tests to verify that the factorial function behaves as expected.

• Save these tests in a separate file, such as test_factorial.py

# test_factorial.py
• import pytest from factorial import factorial
1. def test_factorial_zero(): assert factorial(0) == 1
2. def test_factorial_one(): assert factorial(1) == 1
3. def test_factorial_positive_int(): assert factorial(5) == 120
4. def test_factorial_large_int(): assert factorial(10) == 3628800
5. def test_factorial_negative_int():
• with pytest.raises(ValueError, match="Input must be a non-negative integer."):
• factorial(-5)
Explanation of the Tests
1.test_factorial_zero: Tests that the factorial of 0 returns 1.
2.test_factorial_one: Tests that the factorial of 1 returns 1.
3.test_factorial_positive_int: Tests that the factorial of 5 returns 120.
4.test_factorial_large_int: Tests that the factorial of 10 returns 3,628,800.
5.test_factorial_negative_int: Tests that passing a negative integer raises a ValueError.

26
 Running the Tests with pytest

To run these tests, you would navigate to the directory containing your test file and run
the pytest command in the terminal:

pytest

============================= test session starts

==============================
collected 5 items

test_factorial.py ..... [100%]

27