Unit 2 unit testing

Download Unit 2   unit testing

Post on 16-Aug-2015




4 download

Embed Size (px)


  1. 1. UNIT TESTING UNIT - 2 1 Prepared By: Ravi J Khimani, CSE Department, SLTIET, Rajkot
  2. 2. CONCEPTS First level of testing Refers to testing program units in isolation Commonly understood units are function, procedures or methods Or we can say class in OOP is a unit A program unit is assumed to implement a well defined function providing a certain level of abstraction to the implementation of higher level functions. 2
  3. 3. CONCEPTS It is only natural to test the unit before it is integrated with other units. Thus, a program unit is tested in isolation, that is, in a stand-alone manner Due to two reasons Errors found during testing can be attributed to a specific unit so that it can be easily fixed During unit testing it is desirable to verify that each distinct execution of a program unit produces the expected result 3
  4. 4. CONCEPTS In terms of code details, a distinct execution refers to a distinct path in the unit. Ideally, all possibleor as much as possible distinct executions are to be considered during unit testing. This requires careful selection of input data for each distinct execution 4
  5. 5. CONCEPTS Unit testing has a limited scope. Needs to verify, code works perfectly or not? a programmer needs to test a unit as follows: Execute every line of code. This is desirable because the programmer needs to know what happens when a line of code is executed. In the absence of such basic observations, surprises at a later stage can be expensive. Execute every predicate in the unit to evaluate them to true and false separately. Observe that the unit performs its intended function and ensure that it contains no known errors. 5
  6. 6. CONCEPTS In spite of the above tests, there is no guarantee that a satisfactorily tested unit is functionally correct from a system wide perspective. means that some errors in a program unit can only be found later, when the unit is integrated with other units in the integration testing and system testing phases. It serves no purpose to integrate an erroneous unit with other units for the following reasons: (i) many of the subsequent tests will be a waste of resources (ii) nding the root causes of failures in an integrated system is more resource consuming. 6
  7. 7. CONCEPTS Unit testing is performed by the programmer who writes the program unit because the programmer is intimately familiar with the internal details of the unit. The objective for the programmer is to be satised that the unit works as expected with no errors Unit testing is conducted in two complementary phases: Static unit testing Dynamic unit testing 7
  8. 8. CONCEPTS Static Unit Testing, programmer does not execute Unit, instead of code is examined all possible behavior. Possible issues can be solved by reviewing code in SUT. Dynamic Unit Testing, is totally execution based. After rounds of code reviewing, execution testing is conducted to minimize possible runtime errors. 8
  9. 9. STATIC UNIT TESTING It is undergo of philosophical belief of inspection and correction. Idea behind review is to find possible defects such that they can not be converted to errors further. In SUT, code review applied by two methods, INSPECTION and WALKTHROUGH. 9
  10. 10. STATIC UNIT TESTING Inspection: It is a step-by-step peer group review of a work product, with each step checked against predetermined criteria. Walkthrough: It is a review where the author leads the team through a manual or simulated execution of the product using predefined scenarios. So, any of the method is a systematic approach to examine source code in detail. 10
  11. 11. STATIC UNIT TESTING Goal: to assess the quality of product, not to assess the quality of process to develop the product. Its time consuming process Not perfect up to the level. The key to the success code review is Divide & Conquer. Means having an examiner inspect small parts of the unit in isolation, while making sure of the following: nothing is overlooked the correctness of all examined parts of the module implies the correctness of the whole module. 11
  12. 12. STATIC UNIT TESTING Must assure the each step should simple enough. The objective of code review is to review the code, not to evaluate the author of the code. Therefore, code review must be planned and managed in a professional manner. There is a need for mutual respect, openness, trust, and sharing of expertise in the group. code review consists of six steps : readiness, preparation, examination, rework, validation, and exit. the process produces two types of documents, a change request (CR) and a report. 12
  14. 14. STEP 1: READINESS 14 The author of the unit ensures that the unit under test is ready for review. A unit is said to be ready if it satises the following criteria: Completeness: All the code relating to the unit to be reviewed must be available. Minimal Functionality: The code must have been tested to some extent to make sure that it performs its basic functionalities. Readability: It is essential that the code is highly readable. Complexity: There is no need to schedule a group meeting to review straightforward code which can be easily reviewed by the programmer Requirements and Design Documents: Relevant documents must be available to the reviewer.
  15. 15. STEP 1: READINESS 15 People involved in review process are informed for group meeting before two days. Review Group involves a number of peoples with their roles, which are as follows, Moderator: A review meeting is chaired by the moderator. The moderator is a trained individual who guides the pace of the review process. Author: This is the person who has written the code to be reviewed. Presenter: A presenter is someone other than the author of the code. It is the presenter who presents the authors code in the review meeting for the following reasons:
  16. 16. STEP 1: READINESS 16 an additional software developer will understand the work within the software organization; if the original programmer leaves the company with a short notice, at least one other programmer in the company knows what is being done; The original programmer will have a good feeling about his or her work, if someone else appreciates their work. Record-keeper: The record keeper documents the problems found during the review process and the follow-up actions suggested. Reviewers: These are experts in the subject area of the code under review. Observers: These are people who want to learn about the code under review.
  17. 17. STEP 2: PREPARATION 17 Before the meeting, each reviewer carefully reviews the work package. Each reviewer develops the following: List of Questions: A reviewer prepares a list of questions to be asked, if needed, of the author to clarify issues arising from his or her reading. Potential CR: A reviewer may make a formal request to make a change. These are called change requests rather than defect reports. These reports are not included in defect statistics related to the product. Suggested Improvement Opportunities: The reviewers may suggest how to fix the problems, if there are any
  18. 18. STEP 3: EXAMINATION 18 Includes following activities, The author makes a presentation of the procedural logic used in the code, the paths denoting major computations, and the dependency . The presenter reads the code line by line. The reviewers may raise questions if the code is seen to have defects. Problems are not resolved in the meeting. The record-keeper documents the change requests and the suggestions for fixing the problems
  19. 19. STEP 3: EXAMINATION 19 Includes following activities, The moderator ensures that the meeting remains focused on the review process. At the end of the meeting, a decision is taken regarding whether or not to call another meeting to further review the code. If the review process leads to extensive rework of the code or critical issues are identied in the process, then another meeting is generally convened..
  20. 20. STEP 3: EXAMINATION CHANGE REQUEST 20 A CR includes the following details: Give a brief description of the issue or action item. Assign a priority level (major or minor) to a CR. Assign a person to follow up the issue. Since a CR documents a potential problem, there is a need for interaction between the author Set a deadline for addressing a CR
  21. 21. STEP 3: EXAMINATION 21
  22. 22. STEP 4: RE-WORK 22 At the end of the meeting, the record keeper produces a summary of the meeting that includes the following information. A list of all the CRs, the dates by which those will be fixed, and the names of the persons responsible for validating the CRs A list of improvement opportunities The minutes of the meeting (optional) A copy of the report is distributed to all the members of the review group. After the meeting, the author works on the CRs to x the problems. The author documents the improvements made to the code in the CRs.
  23. 23. STEP 5: VALIDATION 23 The CRs are independently validated by the moderator or another person designated for this purpose. The validation process involves checking the modified code as documented in the CRs and ensuring that the suggested improvements have been implemented correctly. The revised and final version of the outcome of the review meeting is distributed to all the group members.
  24. 24. STEP 6: EXIT 24 It is said to be complete if all of the following actions have been taken: Every line of code in the unit has been inspected. If too many defects are found in a module, the module is once again reviewed after corrections are applied by the author. As a rule of thumb, if more than 5% of the total lines of code are thought to be contentious, then a second revi