1. Helping you make your code better
SonarQube use cases
Helping you make your code better 1

2. Code quality Why worry about code quality ? cheaper code
easier and quicker to test
easier to understand
quicker time to market
quicker turn around and business value

3. How can SonarQube help Metrics
Measure aspects of the code that indicate lower code quality
Duplication
duplicated code is harder to maintain and test
Issues and violations
bugs, deviations from coding standards, bad practices
Test coverage
code needs to be tested for correctness

4. Metrics
Metrics allow you to measure aspects of your code that help you evaluate its quality. There are general metrics that apply to most programming languages, such as
number of lines in a function or procedure (how hard is the code to read)
cyclometric complexity (how hard is the code to understand and also test)
There also ones that are specific to WMB/IIB development, such as
length of a flow (the more nodes in a flow the longer it will take to run and the more resources it will use)
string manipulation load (how many resource intensive string manipulation functions are called)

5. Metrics (cont)
The following shows SonarQube displaying metrics about WMB/IIB code

6. Metrics (cont)
You can then drill down into the metric to find out more

7. Duplication
SonarQube allows you to detect duplicated ESQL in WMB/IIB code
This allows you refactor code that is duplicated to make it easier to maintain. There is a good refence here of why duplicated code is bad -

8. Duplication (cont)
The following shows code that is found to be duplicated and the location in the file where the duplicated code has been found.

9. Issues and violations
SonarQube allows you to report and manage issues and coding violations
One way of looking at this is, that it is doing an automatic code review
It is looking for deviations from your coding standards such as naming standards, similar to what tools such as checkstyle provide (for Java) -
It is looking for potential bugs, such as what you would find in Java if you were using PMD - or findbugs - but the tool works specificall for WMB/IIB development (it has rules for ESQL, XSL, Messagflows, Message Maps)

10. Issues and violations (cont)
Below shows how issues and violations are displayed in the SonarQube dashboard

11. Issues and violations (cont)
Below shows a general coding violation i.e. this is undesirable in any programming language. In this case, an unused variable

12. Issues and violations (cont)
Below shows a general coding violation i.e. this is undesirable in any programming language. Another example, an unused method

13. Issues and violations (cont)
The following is a WMB/IIB specific violation. In this case calling copy message headers as well as copy entire message -

14. Test coverage
Test coverage allows teams to measure how much code that they have tested, so they have more confidence that their tests cover the appropriate businsess logic
We have two (2) methods of capturing test coverage in WMB/IIB
(1) Tracing - using-tracing/
(2) Instrumentation - coverage/

15. Test coverage - tracing
Tracing allows you to capture ESQL coverage by consuming the WMB/IIB tracing log that is enabled while a test case is running. The following shows a summary of coverage for a project.

16. Test coverage – tracing (cont)
The below shows coverage captured while tracing was enabled during a test case. Green indicates tested, red indicates not tested, orange indicates partially tested.

17. Test coverage – instrumentation
Instrumentation involves manipulating the deployed code to create profile points of what code has been executed. It allows capturing coverage of XSL, ESQL, Java (called from inside a flow) and Messageflow/Subflow files.

18. Test coverage – instrumentation (cont)
The below shows coverage captured while instrumentation was enabled during a test case. Green indicates tested, red indicates not tested, orange indicates partially tested.

19. DevOPS – CI/CD use cases
The following slides describe processes that teams can look to follow if they are interested in more “contemporary” development methods
CI – Continuous Integration -
CD – Continuous Delivery -
DevOPS – Development + Operations - of-unit-tests-in-test-automation

20. Simple – developer runs SonarQube
A developer can run the analysis to find issues before they commit
Developer checks out the code and makes changes
Developer reads the analysis looking for issues that she can fix or any code that she can improve
Developer fixes the code
Developer runs the SonarQube static code analysis

21. Simple – developer self check (cont)
Allows developers to self correct
Gives immediate feedback
Provides a sanity check
Benefits
Finding issues here means that others have more confidence in the code they are reviewing later on
Issues fixed here are the easiest to address

22. Build server runs SonarQube
A build server/CI server (Jenkins for example) runs the static code analysis for each change
Developers/team leads/delivery manager can inspect the results and apply any further corrective actions
CI server s the results (including any new violations or drops in quality) to the team/s
CI server runs the SonarQube static code analysis
CI server checks out the code

23. Build server runs SonarQube (cont)
Benefits
Allows the team to be involved in managing quality
Makes managing code quality more enforceable (all the code is being checked)
Considerations
Can be stressful for developers that may feel they are being attacked if the culture doesn’t lend to feedback loops
Feedback is more delayed

24. Build server runs tests
The CI/Build server runs tests and static code analysis
CI server checks out the code
CI server builds the code (a BAR file)
The team can decide how much testing is enough
CI server runs unit tests and records test coverage, then runs SonarQube static code analysis (with test coverage)

25. Build server runs tests (cont)
Benefits
With tests to support them, teams can refactor any issues found with the knowledge that tests can help prevent them from introducing bugs – encourages refactoring and reducing technical debt.
Running the tests all the time means that the team gets immediate feedback when there is an issue with the logic – not when testing starts a few weeks/months later
Business users can use tests to help describe the requirements (BDD)
Considerations
Writing tests is often harder then development

26. Full CI/CD
Teams can use SonarQube as the quality gate that determines if code can go into an environment (test or production). If the tests pass, and the coverage is good and there are no critical issues (good code quality) then teams can deploy.
CI builds (BAR files) that are good can be stored for deployment
CI server checks out the code (tag or branch)
CI server runs unit tests and records test coverage
CI server runs the Sonarqube static code analysis (with test coverage) and checks against minimum quality thresholds
CI server deploys BAR file to test / production

27. Where does MB-Precise fit in ?
MB-Precise is a SonarQube plugin
From SonarQube it provides violations (warnings on bad code) and test coverage
Violations and test coverage can be used to determine if a deployment (BAR file in the case of WMB/IIB) should be deployed/installed
Passing tests, low violations (or maybe even 0) and good test coverage are the pre-requisites on whether code can go to production

28. MB-Precise benefits Provides code duplication checking for ESQL
Provides test coverage for WMB/IIB
Using “tracing” – easier and less invasive
Provides coverage of ESQL files
Using “instrumentation”
Provides coverage for ESQL, Messageflows, Java and XSL

29. MB-Precise benefits (cont)
Currently has 310+ rules for WMB/IIB
Currently has 20+ rules for DP (XSL)

30. More features Diagram generation:

31. Find out more Our website contains more information:
Demos, tutorials and presentations:
You can contact us via our website
Or via