Unit test ???? - is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work. This presentation is all about Unit Testing. Will be beneficial to both the developers and testers to learn from.

1. Unit Testing
Name: Amit Satpathy
No. of Slides: 48
Duration: 2 hours
Date: 18/02/2014

2. 2
Table of Content
• What is Unit?
• Generic Definition of Unit
• Integration of Units
• Why Unit is Important?
• What is Unit Testing?
• Unit Testing Methods (Static and Dynamic)
• Unit testing guidelines for Screen Based Systems

3. 3
What is a Unit ?
• Is it Unit of measurement for software ?
• Is it a computer Unit ?
• Is it the work done by a developer ?
• Is it a logical Unit of source code developed ?

4. 4
Generic definition of a Unit
• A unit is smallest executable/testable piece of
software, which can be compiled or assembled or
linked .
• It is usually the work of a developer and it consists of
several hundreds or fewer lines of source code.

5. 5
How a software product is built ?
• In a Software product the lowest level executable
codes are Units.
• Seamless integration of these Units result in the
intermediate/final product.

6. 6
Integration of Units
• Integration of Units sometimes gives rise to modules
• Modules are sometimes joined to result in as
intermediate product

7. 7
Why Unit is important ?
• Man is the best example
• Mouth, Nose, Eye etc are different units
• Seamless integration of different units results in
complete man
• What if one unit does not function properly ?

8. 8
What is unit testing ?
• The testing performed to show that
– the unit does not satisfy its functional specification
– and/or that its implementation structure does not
match the intended design structure
• When our test reveals such faults, we say there is unit
defect.

9. 9
Unit Testing Methods
• Static Analysis
– is a method used to investigate the structural
properties of the code
• Dynamic Testing
– is a method used to investigate the behavior of the
source code by executing the program on the test
data

10. 10
Static Analysis Considerations
• Syntax
• Unreachable code
• Unconditional branches into loops
• Undeclared variables
• Un-initialized variables

11. 11
Static Analysis Considerations...
• Parameter type mismatches
• Uncalled functions and procedures.
• Variables used before initialization.
• Non usage of function results.
• Possible array bound errors.
• Misuse of pointers

12. 12
Dynamic Unit Testing Considerations
• Interface
• Local data structures
• Boundary conditions
• Independent paths
• Error handling paths

13. 13
Suggested checklist - Interface
• Number of input parameters equal to number of
arguments?
• Parameter and argument attributes match?

14. 14
Suggested checklist….
• Parameters passed in correct order?
• Input only parameters changed?
• Global variable definitions consistent across modules

15. 15
Suggested checklist – I/O
If the unit does I/O
• File attributes correct?
• Open / Close statements correct?
• Format specifications match I/O statements?
• Buffer size match record size?

16. 16
Suggested checklist...
• Files opened before use?
• End of file condition handled?
• I/O errors handled?
• Any textual errors in output information?

17. 17
Suggested checklist - Local Data Structures
• Improper or inconsistent typing
• Erroneous initialization or default values
• Incorrect variable names
• Inconsistent data types

18. 18
Suggested checklist - Error Handling
• Error description unintelligible.
• Error noted does not correspond to error encountered.
• Error description does not provide sufficient
information to assist in determining error.

19. 19
Boundary Value Analysis
• Large number of errors tend to occur at boundaries of
the input domain
• BVA leads to selection of test cases that exercise
boundary values.

20. 20
Boundary Value Analysis…….
• Examples
1.For a range of values bounded by a and b, test (a-
1), a, (a+1), (b-1), b, (b+1).
2.If input conditions specify a number of values n, test
with (n-1), n and (n+1) input values.
3.Apply 1 and 2 to output conditions (e.g., generate
table of minimum and maximum size).
4.If internal program data structures have boundaries
(e.g., buffer size, table limits), use input data to
exercise structures on boundaries.

21. 21
Control Structure Testing
Conditions Can define :
• Relational expression: (E1 op E2), where E1 and E2
are arithmetic expressions. Ex:- E1 <= E2
• Boolean Expression: Boolean variable or relational
expression, possibly preceded by a NOT operator.
NOT(E1 > E2) AND (E3 < E4)
• Compound condition: composed of two or more simple
conditions, Boolean operators and parentheses.
(E1 > E2) AND (E3 < E4)

22. 22
Control Structure Testing...
Errors in expressions can be due to:
• Boolean operator error
• Boolean variable error
• Boolean parenthesis error

23. 23
Control Structure Testing...
• Relational operator error
• Arithmetic expression error
• Condition testing methods focus on testing each
condition in the program

24. 24
Strategies for Control Structure Testing
Strategies proposed include-
• Branch testing - execute every branch at least once.
• Domain Testing - uses three or four tests for every
relational operator.
• Branch and relational operator testing - uses condition
constraints

25. 25
Data Flow Testing
• Selects test paths according to the location of
definitions and use of variables.

26. 26
Loop Testing- Simple Loops
Simple Loops of size n:
– Skip loop entirely
– Only one pass through loop
– Two passes through loop
– m passes through loop where m<n.
– (n-1), n, and (n+1) passes through the loop.

27. 27
Loop Testing-Nested Loops
Nested Loops
• Start with inner loop. Set all other loops to minimum
values.
• Conduct simple loop testing on inner loop.
• Work outwards
• Continue until all loops tested.

28. 28
Break……………………………….

29. 29
Quiz
• Is unit testing necessary and Why?
• How many conditions can be there for Control
structure testing?
• How nested loop structure is tested?
• What is BVA?
• What are the checks for I/O operations?
• What are the checks done in Static checking?

30. 30
Unit testing guidelines
for Screen Based Systems

31. 31
General Considerations
• Make sure that orientation of the place holders through out the
screen should be uniform
• Mandatory field should have a indicator along with the label.
• Try to use uniform alert messages for similar error conditions.
• Example : While checking for non-numeric input in a numeric field
on one screen alert message “Non-numeric data. Please try
again…” and on some other screen the alert “You have entered
invalid data” should not come.

32. 32
General Considerations…
• Timeout expired errors
• Password configuration max length different from
password entry box max length
• Window resize problem - sometimes you cannot resize
windows
• Missing confirmation prompts for save or delete
• When run a report it looks for a path from the
programmer's machine
• Keyboard shortcuts for menus and buttons missing the
underline.

33. 33
Empty screen(without any data)
• Screen layout should be checked with user screen
specification or any standard screen layout which you
want to follow through out
• Check the functionality of buttons, valid responses as well
as invalid responses.
• Example : Submit, Next, Previous, Reset, Add, Update,
Delete etc.
• Ensure that their is no syntax related errors

34. 34
Cursor Positioning
• While entering into the screen the cursor should not point to
the field which is not editable
• Cursor should not go to frame outline by using any cursor
movement keys
• After showing the Alert/Error Message for any field the
cursor focus should come
Option-1 : Old data value and chance is given to the user to
correct it
Option-2 : Old value should be deleted and cursor focus
should be from the beginning of the filed.
Out of this two options follow one through out the unit,
module and package.

35. 35
Browser Related
• If the browser text for largest text size (View-Text Size-
Largest) is selected then the text inside the buttons
should not spill over the button
• Units/Modules should be tested in common browsers
like IE, Firefox, Chrome, Safari etc. across mac, win
and linux based systems.

36. 36
Screen Resolution related
• Screens should be tested with different common
resolutions like 800x600, 1024x768, 640x480 etc.

37. 37
Drop down related
• Verify all the drop downs whether they have selectable items in
them or not.
• Drop down list options can be chosen carefully to convey the
proper meaning. Example : “Employer Iden. No.”, one option in a
drop down list can be written as “Employer Id. No.” for better
clarity.
• While making any drop down list pl. try to put all valid options first
and then put the invalid option towards the end of the list.
• Example : Gender – Instead of this you can write
Male
Unknown
Female
Male
Female
Unknown

38. 38
Labels related
• All labels through out the screen should be uniform as
far are font size, font type are concerned
• Carefully choose the words for the labels & write down
the labels with correct spelling – If the system is for
USA then American Spelling. Example : “Organization”
should be written as “Organization

39. 39
Labels related…
• Labels should also be chosen correctly. Example :
Instead of “Reference Id. Qual” we can write “Ref. Id.
Qualifier” as in this case of “Qual” it can be either
“Qualifier” or “Qualification”.
• Any serial no., if any mentioned in the screen, should
follow some standard. Suggestion : Either they should
be like 1,2,3,…..10,11,12… or they can be
01,02,03,04……10,11,12….. But the mixture of two
standards does not look nice.

40. 40
Invalid set of data
• Pl. check that all the invalid set of data are rejected by
the system. based on the design, each field may have
different set of allowable characters and suitable
validations.
• Pl. check with different combinations of insufficient
mandatory data. i.e. if there are 5 mandatory fields, try
different combinations where at least one of them is
missing.

41. 41
Invalid set of data…
• Check with special characters, if they are not valid for
that field
• Check for the Null value
• Mismatch of field length with column length of the table

42. 42
Valid set of Data
• Check with minimal required data
• Check with data in all the fields
• Different valid combinations of empty & completed
fields
• Handling of Duplicate data
• Functionality of different buttons, valid actions &
invalid actions
• Try quitting with saving and without saving
• Try quitting before logical completion of work.

43. 43
Numeric Field
• Pl. check for non numeric data
• Pl. check for Integer or Decimal as per
design/business rule – type validation
• Check with out of range data – length validation
• Check with minimum & maximum limit – boundary
condition validation
• In case of Amount/Cost/Price fields, there should not
be any chance for truncation before decimal point or
after decimal point.

44. 44
Special Character Checking
• Check inputting of special characters like single-
quote(‘), double (“), comma (,), greater than (>), less
than (<) and ampersand (&) in all alphabetic as well as
alphanumeric fields.
• Also check for special characters like asterisk (*), hash
(#), exclamation mark (!), question mark (?) etc. in all
alphabetic as well as alphanumeric fields.

45. 45
Date validation
• In case of Begin Date and End Date kind of entry in
any screen, make sure that Begin Date should be <=
End Date
• Date validation format should be checked properly.
Suggestion : if the format specified as CCYY/MM/DD
then only dates with this formats should be accepted
but not the dates with CCYY-MM-DD.

46. 46
Screen Navigation & Data flow
• Try different combinations of navigations
• Check for data entered on other screens, look for
truncation, corruption, reformatting & other unwanted
processing
• In any screen check for the Navigation through <TAB>
key and reverse-navigation through <shift-TAB> key.

47. 47
Quiz
• What are various general checks to be carried out on
each screen?
• What are the checks for Invalid Data?
• What are the checks for Numeric field?
• What are the checks for Drop Down related fields?
• What are the checks for Cursor Positioning?

48. 48
Thank you