Unit Testing Procedure

Unit Testing

When does it happen?

• Unit testing will be conducted by each individual developer whenever there is a change to a module by that developer, no matter how small or insignificant the change might seem. Unit testing occurs once the developer has finished making changes to the source code and has successfully integrated the new code into his own private build with a successful compile.

How do you do it?

• Identify the preconditions for the code you wrote.
• Identify the boundary conditions for those preconditions.
• Write assertions to test the boundary conditions.
• Write a small driver file to test up to, on, and over the boundary conditions.
  • If you can test the boundary conditions by conducting a private system test, then you may skip the writing of the driver file.
• Try and cover as many independent paths as you can (not "all logical paths").
• Remember to check the module for adherence to the user manual/prototype.

Documentation and Reporting Criteria

• Since no one has documented their system tests so far, we aren't going to implement it now.

• However,
  Each team member must document unit testing on one (1) method with a cyclomatic complexity > 5.
  • Write a driver to fully test the unit, using the above guidelines.
  • In a separate document, create a table* of test cases you ran.
  • Create the flow graph for the unit and find the basis path
  • Turn in to the QA manager
    • the driver
    • the table of test cases you used
    • the flow graph
    • the basis path you found from the flow graph

     

*See table below.

Last Updated on 3/01/01
By Jonathon Lee