Arunkumar Khannur's Software Testing Knowledge Center
   
 

4.3 Unit Testing

Normal processing paths prior to beginning unit test. Some contracts, where some of the software is COTS, do not permit state visibility into unit testing.

4.3.1. Unit Test Expectations
Unit testing can ideally meet following expectations:
  • Unit testing takes place in development environment and we may need to create test data to follow a particular code path or test specific test cases
  • Ideally, every path/line of code that is new or modified should be executed at least once. If the paths in program element are difficult to test then it is recommended to have a detailed code inspection to verify functionality.
  • All programs and data should be verified for compliance with coding standards and programming style in order to find violation in naming conventions, conditions on usage of go-to, indention in code, and nesting of loops
  • All programs shall have manageable complexity and shall be built on modularity principles. Using techniques like Cyclomatic Complexity, the complexity of code shall be measured, and the same shall be reported.
  • All possible values should be tested for data entry fields, including normal and exception entries, and also unusual entries such as function key press, control-key combinations, etc. This shall be done for all new code and modified code. In some environments, there are tools that will generate test data for this purpose
  • All error cases should be verified and required to end gracefully with the appropriate error data reported (i.e., handle the error; don't allow the program to terminate on an error). This may include executing re-start logic, recovery from the error, or a graceful shutdown.
  • All return values should be verified to ensure they are correctly generated under the correct circumstances.
  • Screen displays and report formats should be verified for format and data accuracy, including appropriate number of decimal places and correct rounding on calculations, particularly for monetary values
  • New or modified help screens and supporting user materials should be verified.
  • Some performance tests may be conducted and used to model or extrapolate behavior. Performance related issues can be addressed at unit level. Any violation of designing standards related to normalization, usage of too many joints and unions in programs etc shall be reported.
  • Units should "clean up" after themselves, releasing any system resources, as appropriate. Use test tools to check for "memory leaks" and inefficient processing paths
  • If specialized hardware is being used, accuracy and functionality tests may be performed to verify correct interaction of the code and hardware, and that the hardware performs according to its specifications.
  • All affected documentation should be updated including in-line code comments and unit/module/function headers, design documents, user manuals, help desk procedures or bulletins, and help files
  • Some error cases or difficult-to-test requirements may be formally verified at this level and/or at the acceptance test level. A unit-level code inspection may be performed during acceptance test to verify non-testable requirements

4.3.2. Unit Test Considerations
Unit Test focuses on:
  • Interface
  • Local data structures
  • Boundary conditions
  • Independent paths
  • Error handling paths

Interface
In unit test, while testing interfaces, we consider:
  • Number of input parameters equal to number of arguments?
  • Parameter and argument attributes match?
  • Parameter and argument units system match?
  • Parameters passed in correct order?
  • Input only parameters changed?
  • Global variable definitions consistent across modules
  • File attributes correct?
  • Open / Close statements correct?
  • Format specifications match I/O statements?
  • Buffer size match record size?
  • Files opened before use?
  • End of file condition handled?
  • I/O errors handled?
  • Any textual errors in output information?

Local Data Structure
In unit test, we verify usage of local data structure in following aspects:
  • Improper or inconsistent typing
  • Erroneous initialization or default values
  • Incorrect variable names
  • Inconsistent data types
  • Overflow, underflow, address exceptions

Boundary Conditions
In unit test, we verify boundary conditions in following aspects:
  • Lower bound and upper bound values of defined range of values of variables
  • Values of variables beyond acceptable limits

Independent Paths
Unit test shall verify independent paths in following aspects:
  • Execution of possible branch statements
  • Single entry and single exit of loops
  • Handling of Go-Tos
  • Balance of beginning and ending of embedded statements and loops
  • Initialization and termination conditions of loops

Error Handling
Unit test shall consider error handling related aspects:
  • Error description unintelligible
  • Error noted does not correspond to error encountered
  • Error condition handled by system run-time before error handler gets control
  • Exception condition processing incorrect

Error description does not provide sufficient information to assist in determining error.
 
 
 
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
         
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
STEP-AUTO Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
URL: www.isqtinternational.com
Email: khannur@isqtinternational.com
Skype: arun.isqt