1. Nguyen Ngoc Anh
anhnn3@fpt.com.vn
Fu Hoa Lac, 3- 2013

2. Objectives
o Why testing?
o Basic principles
o How to choosing test case
o Test-First Programming
o Introduction to Junit
o Let’s do together!!!!
FUAgile: Unit Testing Basic 2

3. CRISIS
Numbers:
4.4 million cars recalled
Billions of $ loss.
Damage the brand
FUAgile: Unit Testing Basic 3

4. Desire vs. Reality
Desired Reality
Requirement
gap Implementation
Design
testing
FUAgile: Unit Testing Basic 4

5. Why testing?
o Ensuring QUALITY
o Managing RISKS
o Optimizing Return-On-Investment (ROI)
o Professionalism
FUAgile: Unit Testing Basic 5

6. Typical Production model
Requirement
Design
Implement
Test
FUAgile: Unit Testing Basic 6

7. Bug cost
FUAgile: Unit Testing Basic 7

8. Testing level
o Unit testing
o On individual unit of source code (function, class, etc.)
o Smallest testable part
o Developer testing
o Integration testing
o On groups of modules
o System testing
o On complete integrated system
FUAgile: Unit Testing Basic 8

9. Basic Principles
o Be systematic
o Haphazard testing & exhaustive testing are impossible.
o test cases must be chosen carefully and systematically
o Do it early and often
o Don’t leave testing until the end  debugging longer and
more painful
o test-first programming
FUAgile: Unit Testing Basic 9

10. Basic Principles
o Automate it
o Nothing makes tests easier to run, and more likely to be
run, than complete automation.
o For regression test
FUAgile: Unit Testing Basic 10

11. Why Testing is Hard
o We want to
o know when product is stable enough to launch
o deliver product with known failure rate (preferably low)
o offer warranty?
FUAgile: Unit Testing Basic 11

12. Why Testing is Hard
o But
o it’s very hard to measure or ensure quality in software
o residual defect rate after shipping:
• 1 - 10 defects/kloc (typical)
• 0.1 - 1 defects/kloc (high quality: Java libraries?)
• 0.01 - 0.1 defects/kloc (very best: Praxis, NASA)
o exhaustive testing is infeasible
o statistical testing doesn’t work for software
FUAgile: Unit Testing Basic 12

13. Find bugs as cheaply and quickly as possible!
FUAgile: Unit Testing Basic 13

14. Choosing Test Cases
o Key Idea #1: Partition the Input Space
o input space is very large, but program is small  so
behavior must be the “same” for whole sets of inputs
o ideal test suite
o identify sets of inputs with the same behavior
o try one input from each set
FUAgile: Unit Testing Basic 14

15. Choosing Test Cases
Ex: multiply : BigInteger x BigInteger  BigInteger
partition BigInteger into:
BigNeg, SmallNeg, -1, 0, 1, SmallPos, BigPos
pick a value from each class
-265, -9 -1, 0, 1, 9, 265
test the 7 × 7 = 49 combinations
FUAgile: Unit Testing Basic 15

16. Choosing Test Cases
Ex2: max : int vs int  int
partition into:
a < b, a = b, a > b
pick value from each class
(1, 2), (1, 1), (2, 1)
FUAgile: Unit Testing Basic 16

17. Choosing Test Cases
0
FUAgile: Unit Testing Basic 17

18. Choosing Test Cases
o Key idea #2: Boundary testing
o include classes at boundaries of the input space
zero, min/max values, empty set, empty string, null
o why? because bugs often occur at boundaries
o off-by-one errors
o forget to handle empty container
o overflow errors in arithmetic
FUAgile: Unit Testing Basic 18

19. Choosing Test Cases
EX: Find max value in a list of nonnegative integers. Assuming
that list is not empty.
public static int max(List<Integer> l) { ... }
list length: length 0, length 1, length 2+
max position: start, middle, end of list
value of max: MIN_INT, negative, 0, positive, MAX_INT
FUAgile: Unit Testing Basic 19

20. Coverage
o all-statements: is every statement run by some test case?
(common goal)
o all-branches: if every direction of an if or while statement (true
or false) taken by some test case?
o all-paths: is every possible combination of branches – every
path through the program – taken by some test case?
FUAgile: Unit Testing Basic 20

21. Test-first programming
2 approaches:
Code  Tests  Fix bugs (painful)
Write tests  Code Test-first programming
What is your choice?
FUAgile: Unit Testing Basic 21

22. Test-first programming
write tests before coding
specifically, for every method or class:
1) write specification
2) write test cases that cover the spec
3) implement the method or class
4) once the tests pass (and code coverage is sufficient), you’re done
FUAgile: Unit Testing Basic 22

23. JUnit
o Unit testing automation framework for Java
o Can do integration test
o Integrated in IDEs (Eclipse, NetBeans, IntelliJ, etc.)
o Must have tool for Java developers
http://www.junit.org/
FUAgile: Unit Testing Basic 23

24. JUnit
o A JUnit test case start with @Test
o Test case name start with testXXX()
o Using assertEquals, assertTrue, assertFalse…
@Test
public void testMaxAtStart(){
ArrayList<Integer> list = new ArrayList<>();
//add 5,2,3 to list
assertEquals(MyClass.Max(list), 5);
}
FUAgile: Unit Testing Basic 24

25. JUnit
o If you expect an exception using
@Test(expected = SomeTypeOfException.class)
@Test(expected = IllegalArgumentException.class)
public void testMaxAtStart(){
ArrayList<Integer> list = new ArrayList<>();
MyClass.Max(list)
}
FUAgile: Unit Testing Basic 25

26. Let’s do together
Using Test-First programming
Ex1: Write a function with parameter is an integer n, if n<0 throw
IllegalArgumentException; otherwise
• if n%3==0 return “Fizz”;
• If n%5==0 return “Buzz”;
• If n%3==0 and n%5==0 return “FizzBuzz”;
• Else return the number itself
public static String fizzBuzz(int n) { ... }
FUAgile: Unit Testing Basic 26

27. Let’s do together
Using Test-First programming
Ex2: Find max value in a list of nonnegative integers. Assuming
that list is not empty.
public static int max(List<Integer> list) { ... }
FUAgile: Unit Testing Basic 27

28. Let’s do together
Using Test-First programming
Ex3: Find the union of 2 arrays of integers.
public static int[] union(int[] arr1, int[] arr2) { ... }
FUAgile: Unit Testing Basic 28