Fixing Errors Found

This topic explains how and why to repair the various types of errors that Jtest finds in your code.

Learning More About Errors Found

Before you begin to fix the errors found, you should explore them to determine what caused each error. For example, if Jtest reports an uncaught runtime exception, you should examine the information related to that exception to determine whether it is the result of an incorrectly behaving method, an unexpected argument, a correctly behaving method, or a developer-use only method. If Jtest reports a coding standard violation, you should look at the information related to that violation to determine whether or not it is the result of coding standard that you want to enforce for the current project.

If you performed your test in the Project Testing UI, errors found are displayed in the Project Testing UI's Results panel. To learn more about this panel's branches and available options, see Understanding the Results Panel and Exploring and Customizing Project Test Results.

If you performed your test in the Class Testing UI, errors found are displayed in the Class Testing UI's Errors Found panel. To learn more about this panel's branches and available options, see Understanding the Errors Found Panel and Exploring and Customizing Class Test Results.

Both panels classify errors found into four categories:

• Static Analysis Violations
• Design by Contract Violations
• Uncaught Runtime Exceptions
• Specification/Regression Errors

Static Analysis Violations

During static analysis, Jtest automatically tests your code for possible coding standard violations. Coding standard violations are reported under the Static Analysis heading. Jtest reports the following information for each violation found:

1. Rule violation: Jtest presents each rule violation by listing the rule, a rule ID, and a number that indicates the severity level of the rule. The rule can be one of 174 built in rules provided by Jtest or a user-defined rule.
2. Suggestion: To see a suggestion of how to avoid this coding standard violation, expand the rule violation branch.
3. Line Reference: To view a line reference of where the coding standard violation occurred, expand the suggestion branch. If you double click the line reference, the source viewer will open with the line of code that produced the violation highlighted in yellow.

Design by Contract Violations

During dynamic analysis, Jtest creates test cases that verify the specifications included in each class's DbC-format contact. Violations found are reported under the Design by Contract Violations heading. Design by Contract violations are organized according to the nature of the violation. This heading contains the following violation categories:

• @pre violations: Contains information about violations that occur when a method is called incorrectly.
• @post violations: Contains information about violations that occur when a method does not return the expected value.
• @invariant violations: Contains information about violations that occur when an @invariant contact condition is not met.
• @assert violations: Contains information about violations that occur when an @assert contact condition is not met.

Each error message includes file/line information as well as stack trace and calling sequence information.

Uncaught Runtime Exceptions

During dynamic analysis, Jtest automatically creates and executes test cases for each class's methods; it also executes any user-defined test cases that you have added. Exceptions found from automatic and user- defined test cases are reported under the Uncaught Runtime Exceptions heading. Jtest reports the following information for each exception found:

1. Exception Description: Jtest presents each uncaught runtime exception by listing the method that produced the exception, followed by a description of the exception that was thrown.
2. Stack Trace: To see the stack trace, as well as a line reference, expand the branch that displays the exception description. If you double click the line reference, the source viewer will open with the line of code that produced the exception highlighted in yellow. To see the calling sequence that produced the exception, expand the Test Case Input branch.
3. Test Case: To view the test case that Jtest generated to find this uncaught runtime exception, right click Test Case Input and choose View Example Test Case from the shortcut menu.

Specification/Regression Errors

Jtest performs automatic regression testing on a class after the class has been tested at least once. Jtest will compare results from old tests with the current test to ensure that new errors are not introduced into the code after modification. Inconsistencies between old test runs and the current test are reported under Specification and Regression Errors in the Errors Found panel of the Class Testing UI.

Fixing Errors Found

This section offers suggestions on how to fix the errors that Jtest found.

Coding Standard Enforcement (Static Analysis) Violations

Violation Needs to Be FIxed

• Description: The rule violation indicates a violation that needs to be fixed.
• Repair: Repair the code to follow the coding standard. For a complete explanation of a particular coding standard, see Built-in Static Analysis Rules.
• Benefit of Repair: Reduced opportunity for errors to enter into the code.

Violation Does Not Apply

• Description: The coding standard does not apply to your current project, or your development team has decided not to enforce the coding standard.
• Repair: Right click the node that lists the violation, then select Disable This Rule from the shortcut menu. The rule can be re-enabled in the Global Test Parameters.
• Benefit of Repair: Violations of this rule will not be reported in future tests.

Design By Contract Violations

• Description: Design by Contract violations indicate either an error in the code or an error in the contract.
• Repair: Determine if the problem is in the code or in the contract, then make the appropriate modifications.
• Benefit of Repair: The code or contract has been fixed.

White-Box Testing Errors

Incorrectly Behaving Method

• Description: The method is behaving incorrectly; the method shouldn't throw an exception for those arguments.
• Repair: Repair the method's code so that it behaves correctly.
• Benefit of Repair The code has been fixed.

Unexpected Arguments

• Description: The method is not supposed to handle those arguments; an exception is thrown because the method is not expecting those arguments.
• Repair: If the arguments are illegal, either add an @pre condition to the method (this is the recommended repair), or throw an IllegalArgumentException.
• Benefit of Repair: The code is documented, easier to maintain, and easier to change. The code explicitly says what arguments the method handles and which ones it doesn't. The error messages when using illegal arguments are clarified. Encapsulation is enforced. When the method is passed arguments that it is not supposed to handle, it should throw an IllegalArgumentException. If this is not done, one of the following things will occur:
  • The method throws an exception exposing internal implementation details of the method, hence, violating encapsulation.
  • The method doesn't throw an exception when passed illegal arguments. Instead it returns a value without any meaning or leaves the program in an inconsistent state.

Correctly Behaving Methods

• Description: The method is behaving correctly; the output of the method is to throw an Exception.
• Repair: Either add an @exception tag to the document that the method throws that exception (this is the recommended repair), or specify the type of exception in the method's throws clause.
• Benefit of Repair: The code is documented (the code explicitly says that the method can throw that kind of exception) and easier to maintain. Someone looking at the code later on will know whether the method is throwing an exception because the code has a bug or because the code is supposed to throw an exception.

Developer Use Only Methods

• Description: The method is never sent those arguments.
• Repair: Do one of the following:
  • Add an @pre condition to that method (this is the recommended repair).
  • Decrease the accessibility of the method (e.g., set it to private).
  • Throw an IllegalArgumentException.
• Benefit of Repair: Someone looking at the code later on will know whether the program is throwing an exception because the code is incorrect or because the code is not supposed to handle those arguments.

Specification/Regression Errors

Modification-Related Error

• Description: Jtest reports a specification/regression error for code that you recently modified.
• Repair: If the result is unexpected, fix the code to restore the original functionality. If it is expected, change the reference value that Jtest uses for the related test case.
• Benefit of Repair: Errors are removed or Jtest checks the test case against the correct reference value in future test runs.