1. Unit Testing -Ranjit Shewale jcrvs@hotmail.com

2. Contents  Scope  Owner  Approach  Conventional approach  Object oriented approach  Tips for the OOT  Web  Q & A

3. Scope  When does unit testing start? –As soon as the coding starts; Developer writes the first line of code  When does it end? –When project reaches integration phase on module level –Can also be when say 90% of test cases have status pass

4. Owner  Who is the owner of unit testing?  Developer –Release criteria needed to release the build/code to test team  Tester –Verify what the piece of code is intended to do –Verify it handles negative/exceptional conditions

5. Approach - UT  Which options do I have?  Black box –Drivers needed for the same –Techniques as input validation testing, boundary value analysis and category partitioning my be used

6. Approach- Black Box  Input validation –Validation of the input values passed to a function –Check for regular values, negative values, int values, long values, float values –E.G. Embedded systems needs to be coded with data types “short” instead of “int” and systems expecting huge transaction data may need “long” data types instead of “int” and so forth

7. Approach- Black Box  Boundary value analysis –The boundary conditions should be considered for the input and passed to the functions –E.G. If requirements checklist for the function mentions a range for a parameter as 1-100 then boundary conditions as 0,1,2,50,99,100,101 should be considered in unit testing

8. Approach- Black Box  Category partitioning –An technique to split input values for a function to test into sub domains and handle input on sampling basis for testing –E.G. If requirements checklist for the function mentions a range for a parameter as –40 to100, then the input domain can be split into positive numbers and negative numbers. On sampling basis the test values for unit testing can be (– 40,-10,-1,0,1,25,100)

9. Approach - UT White box –Drivers needed for the same –Technique as coverage and Conventional debugging can be used –Coverage tools can be used for the same

10. Approach- White Box  Coverage testing –This includes statement coverage, branch coverage, conditional coverage is covered –Coverage statistics can be one of important release criteria's for the software

11. Conventional Structural Testing Approach  Structural testing was targeted to the procedural programming practice  This was discussed in earlier slides  The unit for testing was a “function”

12. Object Oriented Testing Approach  The scope broadens as the object oriented programming was adopted by IT industry  Unit for testing is changed to “class”  Structural testing is sub-set of OOT

13. Tips for OOT  In addition to the member function testing the following should also be considered –Member variable Effects of change in the value before and after a function is being called E.G. A function may have a pre-condition that member variable “XYZ” must be initialized and have value in a range 1-100 etc

14. Tips for OOT –Integration of member functions of the class Sequence of calling member functions E.g. A function “ABC” may have a precondition that it needs a file generated to start processing it and one of the other member say “XYZ” function may be handling this task and hence this condition should be satisfied before function “ABC” is called

15. Tips for OOT –Inheritance In case of inheritance it is assumed that the base class is already unit tested Testing task of new member functions and member variables Again the function sequencing of the of the base class and new derived class should be considered

16. Tips for OOT –Polymorphism Function overloading –This can be handled in structural testing manner –E.g. Fn(int) and Fn(float) can be tested using structural approach –Consider the default argument case as well Dynamic binding –Object wise dynamic binding needs to be tested –E.g. If Base::fn{} is pure virtual function and Inherited class IH1::fn{} and IH2:fn{} are inherited classes then function testing of fn{} should be done considering both objects of classes IH1 and IH2

17. Tips for OOT  Exceptional testing should not be ruled out

18. Web  The unit can change according to the company and project  Some use unit as “web screen” for testing  Various techniques as Input validation, boundary condition, UI testing are considered as part of testing  Some project even consider the functionality of the web screen as part of unit testing

19. Q & A