Unit Testing -Ranjit Shewale

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

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

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

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

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

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 then boundary conditions as 0,1,2,50,99,100,101 should be considered in unit testing

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)

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

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

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”

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

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 etc

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

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

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

Tips for OOT  Exceptional testing should not be ruled out

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

Q & A