Unit Testing for MultiFunctionPrinter

This article discusses the approach and test cases for unit testing MultiFunctionPrinter. It covers 100% code coverage test cases and additional test cases for data coverage. Defects found during testing are also listed with their descriptions. The article is useful for software testers looking to improve their testing skills.

<Project 1>
Unit Test
<Version>
<Date>
<Your Name>

<Project 1>
Table of Contents
1. Unit Test 1
1.1 APPROACH 1
1.2 100% CODE COVERAGE TEST CASES 3
1.2.1 Test Case 1 3
1.2.2 Test Case 2 3
1.2.3 Test Case 3 3
1.3 ADDITIONAL TEST CASES FOR DATA COVERAGE 4
1.3.1 Test Case 1 4
1.3.2 Test Case 2 4
1.3.3 Test Case 3 4
2. DEFECTS 5
2.1 DEFECTS 5
2.1.1 Defect 1 5
2.1.2 Defect 2 5
Software Unit Test Page ii

<Project 1>
1. Unit Test
1.1 Approach
Unit testing is a software testing, that is done as the first level testing. The testing focuses on
testing individual functions, methods or component of a software, using a White Box Testing
approach (Beck & Gamma, 2004). With unit testing the smallest testable software component is
subjected to specific tests using carefully selected inputs and is characterized with having a
single output only (Beck & Gamma, 2004).
To carry out unit testing, one has to design tests that aim to test the smallest testable code units of
a software (Marick, 1995). In this case, the smallest testable unit is a method within a class. The
goals and objectives of unit testing is to identify failures at the functions level and help in
improving the quality of code (Marick, 1995). The test approach seeks to verify if a given
function, given a set of carefully selected data inputs, is able to process and return proper values,
and whether it can handle failures gracefully (Wick, Stevenson, & Wagner, 2005).
In big software projects, testing all the functions of a program is not possible, as such,
completion of unit test is determined by set levels or acceptable percentage of code that has to be
tested before integration can commence.
Unit testing is essentially a white-box testing approach (Wick, Stevenson, & Wagner, 2005).
White-Box testing focuses on verifying the internal implementation/design or structure of a
software; with white-box testing, inputs are choses to verify the internal working of a program's
code (Wick, Stevenson, & Wagner, 2005).
Code coverage refers to the percentage of program code that is covered through automated
testing (Choudhury et.al, 2017). The measure estimates the amount of code executed during a
test run. As highlighted before, performing unit tests on all functions of a big software is
impossible, as such, an acceptable level of coverage has to be set. The acceptable level of tests is
verified through code coverage (Choudhury et.al, 2017). It helps in knowing if acceptable levels
have been achieved or more tests are needed. It also aids in avoiding test entropy (Choudhury
et.al, 2017). On the other hand, data coverage Is an analysis that helps in determining if auto
generated data is sufficient for performing all tests.
Software Unit Test Page 1

<Project 1>
Test Characteristics Fast: has to provide feedback within a short timeframe Complete: test case is complete if it covers the entire codebase and catches any type of
errors that may come as code is changed (Choudhury et.al, 2017). Reliable: test suite that provides accurate and consistent feedback (Ammann & Offutt,
2016) Isolated: the test can run in isolation without affecting any other test suit Maintainable: a suit that is easy to manipulate e.g. adding and removing Expressive: is descripting of the test being done.
Test cases are written by a software tester who also carries the tests. During testing, a failure of a
UT indicates a defect in the code. Any defective code is returned to the developer to quickly fix
the bug before being re-tested again.
1.2 100% Code Coverage Test Cases
1.2.1 Test Case 1
Test case name: Test changing printer function
Method being tested: setFunction(Function f)
Short Description: the test aims to verify if the setFunction is able to change the default setting
of the printer from PRINT to either SCAN or COPY as the specification states.
Input Data to constructor and/or method you are testing: Function.SCAN
Expected Results: currentFunc should be SCAN
1.2.2 Test Case 2
Test case name: Test setting number of pages parameters
Method being tested: setPages(int p)
Short Description: the test aims to verify if the method works correctly. With the current
function set to SCAN, the method should set pages to 0 regardless of the value passed. This is
because the method should only set pages only when the current function is PRINT or COPY,
else 0
Software Unit Test Page 2

<Project 1>
Input Data to constructor and/or method you are testing: set current function to SCAN and pass
20 as a parameter
Expected Results: parameter pages should be 0
1.2.3 Test Case 3
Test case name: Test changing the function and pages parameter value
Method being tested: settings (Function f, int p)
Short Description: We seek to verify if the method sets the parameter pages and changes the
current function given a function and a number value. The method should only set the pages and
change the function if the function passed is either PRINT or COPY
Input Data to constructor and/or method you are testing: FUNCTION.COPY and 20
Expected Results: current function should be COPY and parameter pages should be 20
1.3 Additional Test Cases for Data Coverage
1.3.1 Test Case 1
Test case name: Test changing printer function
Method being tested: setFunction(Function f)
Short Description: the test aims to verify if the setFunction is able to change the default setting
of the printer from PRINT to either SCAN or COPY
Input Data to constructor and/or method you are testing: Function.SCAN
Expected Results: currentFunc should be SCAN
1.3.2 Test Case 2
Test case name: Test setting number of pages parameters
Method being tested: setPages(int p)
Short Description: the test aims to verify if the method works correctly. With the current
function set to SCAN, the method should set pages to 0 regardless of the value passed. This is
because the method should only set pages only when the current function is PRINT or COPY,
else 0
Software Unit Test Page 3

<Project 1>
Input Data to constructor and/or method you are testing: set current function to SCAN and pass
20 as a parameter
Expected Results: parameter pages should be 0
1.3.3 Test Case 3
Test case name: Test changing the function and pages parameter value
Method being tested: settings (Function f, int p)
Short Description: We seek to verify if the method sets the parameter pages and changes the
current function given a function and a number value. The method should only set the pages and
change the function if the function passed is either PRINT or COPY
Input Data to constructor and/or method you are testing: FUNCTION.COPY and 20
Expected Results: current function should be COPY and parameter pages should be 20
2. Defects
This section lists all identified defects
2.1 Defects
2.1.1 Defect 1
Method/Constructor: set Function (Function f)
Defect Description: The test tried to change the current function from the default PRINT to
SCAN. The specification of the method states that the function should be able to set current
function to PRINT, COPY, SCAN, However, the test failed while trying to set current function to
SCAN
How Found: The defect was found by test case 1; “Test changing printer function”. The function
was subjected to test by passing the parameter FUNCTION.COPY.
2.1.2 Defect 2
Method/Constructor: setPages (int p)
Defect Description: The function was able to set the number of pages, however, as required in
the function description, it can only set number of pages if the current function is either COPY
or PRINT. In this case, the current function was set to SCAN, then a parameter of 20 pages
Software Unit Test Page 4

<Project 1>
passed to the function. The expected result was 0 since it should set 0 if the current function is
not COPY or PRINT. However, the actual result was 20, indicating that the constraint of
current function was not checked.
How Found: The defect was found by test case 2; “Test setting number of pages parameters”
The test current function was set to SCAN and then a parameter of 20 pages passed to the
function.
The Junit Test code
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import static org.junit.Assert.*;
public class MultiFunctionPrinterTest {
public MultiFunctionPrinterTest() {
}
@BeforeClass
public static void setUpClass() {
}
@AfterClass
public static void tearDownClass() {
}
@Before
public void setUp() {
}
@After
public void tearDown() {
}
/**
* Test of setFunction method, of class MultiFunctionPrinter.
*/
@Test
public void testSetFunction() {
System.out.println("setFunction");
MultiFunctionPrinter instance = new MultiFunctionPrinter();
MultiFunctionPrinter.Function f = MultiFunctionPrinter.Function.SCAN;
instance.setFunction(f);
MultiFunctionPrinter.Function expResult =
MultiFunctionPrinter.Function.SCAN;
Software Unit Test Page 5

<Project 1>
assertEquals(expResult, instance.getFunction());
}
/**
* Test of setPages method, of class MultiFunctionPrinter.
*/
@Test
public void testSetPages() {
System.out.println("setPages");
int p = 20;
MultiFunctionPrinter instance = new MultiFunctionPrinter();
//FIRST SET Current function to SCAN
instance.setFunction(MultiFunctionPrinter.Function.SCAN);
//Now try to set pages
instance.setPages(p);
int expResult = 0;
assertEquals(expResult, instance.getPages());
}
/**
* Test of settings method, of class MultiFunctionPrinter.
*/
@Test
public void testSettings() {
System.out.println("settings");
MultiFunctionPrinter instance = new MultiFunctionPrinter();
MultiFunctionPrinter.Function f = MultiFunctionPrinter.Function.COPY;
int p = 20;
instance.settings(f, p);
MultiFunctionPrinter.Function expResult =
MultiFunctionPrinter.Function.COPY;
//check function
assertEquals(expResult, instance.getFunction());
//check pages
assertEquals(p, instance.getPages());
}
}
Software Unit Test Page 6

<Project 1>
References
Ammann, P., & Offutt, J. (2016). Introduction to software testing. Cambridge University Press.
Beck, K., & Gamma, E. (2004). Junit, testing resources for extreme programming. URL: www.
junit. org) 2Planned for release in.
Choudhury, P. P., Dihidar, K., Khan, A. R., Verma, R., & Sarkar, P. (2017). Software
measurements and metrics: Role in effective software testing. Data in
Brief, 3(2017), 593-596.
Gamma, E., & Beck, K. (2000). Junit, testing resources for extreme programming.
Hunt, A., & Thomas, D. (2003). Pragmatic unit testing in Java with JUnit. The Pragmatic
Bookshelf.
Marick, B. (1995). The craft of software testing: subsystem testing including object-based and
object-oriented testing. PTR Prentice Hall.
Massol, V., & Husted, T. (2003). Junit in action. Manning Publications Co..
Myers, G. J., Sandler, C., & Badgett, T. (2011). The art of software testing. John Wiley & Sons.
Olan, M. (2003). Unit testing: test early, test often. Journal of Computing Sciences in
Colleges, 19(2), 319-328.
Rainsberger, J. B. (2004). JUnit recipes: practical methods for programmer testing.
Wick, M., Stevenson, D., & Wagner, P. (2005, February). Using testing and JUnit across the
curriculum. In ACM SIGCSE Bulletin (Vol. 37, No. 1, pp. 236-240). ACM.
Software Unit Test Page 7