These 2 practices are grouped in one page as ONAP uses Sonar which addresses both practices.

Code Coverage

Provide a measure to understand which part (%) of the code has been tested

A way to detect:

  • dead code
  • code that is not so often used but still critical (upgrade)

For ONAP, Sonar is available at sonar.onap.org

Tips

The higher the better (but still this is not an absolute guarantee)

  • Coverage for incubation 30-50 %
  • Coverage for mature 50-70 %
  • Coverage for core 70-80 %

Depending on the project state:

  • Static Code Analysis for incubation: Recommended
  • Static Code Analysis for mature: Recommended

Static Code Analysis for core: Mandatory for each major release. Because the tool generates significant false-positive and thus required a significant effort, the practice not must be conducted in the latest release build

3 Comments

  1. Gildas Lanilis

    Practice approved by TSC 2017-07-13 (topic #10). PDF Summary of materials presented.

  2. Chris Lott

    I am increasingly understanding the comment above re "significant false positives" from Sonar.  How do you suggest we might suppress them to reveal the genuine issues among all the chaff?



    1. Mark Leonard

      Java code can be updated to have the NOSONAR comment, but this is far from ideal as a solution.

      If the exception object is logged (not just the message) this would stop the Sonar violation. 
      Is there a reason not to log the exception here? For example, would logging the entire stack trace (perhaps at DEBUG level only) result in a Fortify issue? Would this be viewed as a possible security violation (by revealing implementation details)? If this is the case, we should update the rules set on the SonarQube server.