Helping you make your code better

Slides:



Advertisements
Similar presentations
® IBM Software Group © 2010 IBM Corporation What’s New in Profiling & Code Coverage RAD V8 April 21, 2011 Kathy Chan
Advertisements

Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
Continous architecture analysis in 3D. 2 Stefan Rinderle Kontinuierliche Architekturanalyse in 3D ○ Bachelor an der HS Karlsruhe ○ Master "Software Engineering"
Continuous Integration for Databases Learn how to automate your build and test Steve Jones Red Gate Software Part II of the Continuous Delivery for Databases.
CONTINUOUS INTEGRATION, DELIVERY & DEPLOYMENT ONE CLICK DELIVERY.
Unit 16 Procedural Programming
Introduction to Software Testing (Paul deGrandis) [Reading assignment: Chapter 15, pp and notes by Paul deGrandis]
DevOps Jesse Pai Robert Monical 8/14/2015. Agile Software Development 8/14/2015© 2015 SGT Inc.2.
CSCE 548 Code Review. CSCE Farkas2 Reading This lecture: – McGraw: Chapter 4 – Recommended: Best Practices for Peer Code Review,
ISV Innovation Presented by ISV Innovation Presented by Business Intelligence Fundamentals: Data Cleansing Ola Ekdahl IT Mentors 9/12/08.
Database Change Management One solution to an often complex problem Kevin Hurwitz Headspring Systems
QUALITY ASSURANCE PRACTICES. Quality Plan Prepared and approved at the beginning of project Soft filing system approach followed. Filing location – –
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Discussion on Testing Simantics Technical Board Meeting
(1) Introduction to Continuous Integration Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of.
(1) Introduction to Continuous Integration Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of.
Discussion on Testing Simantics Technical Board Meeting
Copyright 2015, Robert W. Hasker. Continuous Inspection  Code reviews  Powerful tool  Difficult to ensure meaningful reviews take place  Static analysis.
Build and Deployment Process Understand NCI’s DevOps and continuous integration requirements Understand NCI’s build and distribution requirements.
T EST T OOLS U NIT VI This unit contains the overview of the test tools. Also prerequisites for applying these tools, tools selection and implementation.
Continuous Deployments using SSDT
Findbugs Tin Bui-Huy September, Content What is bug? What is bug? What is Findbugs? What is Findbugs? How to use Findbugs? How to use Findbugs?
Continuous Delivery and Quality Monitoring 1 iCSC2016, Kamil Henryk Król, CERN Continuous Delivery and Quality Monitoring Kamil Henryk Król CERN Inverted.
SOFTWARE TESTING TRAINING TOOLS SUPPORT FOR SOFTWARE TESTING Chapter 6 immaculateres 1.
Continuous Delivery and Quality Monitoring
Joonas Sirén, Technology Architect, Emerging Technologies Accenture
Don’t Forget Security When Delivering Software
Presented by Rob Carver
Agenda:- DevOps Tools Chef Jenkins Puppet Apache Ant Apache Maven Logstash Docker New Relic Gradle Git.
Open-O Integration Project Introduction
Stress Free Deployments with Octopus Deploy
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Continuous Delivery- Complete Guide
AESA – Module 8: Using Dashboards and Data Monitors
Chapter 14: System Protection
Logger, Assert and Invariants
SonarQube and Sonatype Nexus IQ Server
Chapter 18 Maintaining Information Systems
What’s New in Visual Studio 2017
API Testing and Continuous Integration
CIS 207 Competitive Success-- snaptutorial.com
CIS 207 Education for Service-- snaptutorial.com
CIS 207 Teaching Effectively-- snaptutorial.com
1 Oregon State University
Advantages OF BDD Testing
CodePeer Update Arnaud Charlet CodePeer Update Arnaud Charlet
Design and Programming
Helping you make your code better
CodePeer Update Arnaud Charlet CodePeer Update Arnaud Charlet
Simplified Development Toolkit
Continuous deployment best practices, methods and tools.
Mock Object Creation for Test Factoring
Devops Jenkins as CI/CD tool Created By: Amrit Choudhary
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Continuous Integration
Presented by : Chirag Dani & Dhaval Shah
Program Design Language (PDL)
Introduction to VSTS Database Professional
Bringing more value out of automation testing
PLANNING A SECURE BASELINE INSTALLATION
DEVOPS & THE FUTURE OF TESTING
SSDT, Docker, and (Azure) DevOps
Java Code Review with CheckStyle
SSDT, Docker, and (Azure) DevOps
Testing Maximo Time to automate?
Jamie Cool Program Manager Microsoft
SSDT, Docker, and (Azure) DevOps
Open Source Tool Based Automation solution with Continuous Integration and end to end BDD Implementation Arun Krishnan - Automation Manager Maria Afzal-
Samir Behara, Senior Developer, EBSCO
Presentation transcript:

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

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

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

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)

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

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

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 - https://en.wikipedia.org/wiki/Duplicate_code

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.

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) - http://checkstyle.sourceforge.net/ It is looking for potential bugs, such as what you would find in Java if you were using PMD - https://pmd.github.io/ or findbugs - http://findbugs.sourceforge.net/, but the tool works specificall for WMB/IIB development (it has rules for ESQL, XSL, Messagflows, Message Maps)

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

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

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

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 - http://bettercodingtools.com/r164/

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 - http://bettercodingtools.com/message-broker-test-coverage- using-tracing/ (2) Instrumentation - http://bettercodingtools.com/message-broker-test- coverage/

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.

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.

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.

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.

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 - https://martinfowler.com/articles/continuousIntegration.html CD – Continuous Delivery - https://martinfowler.com/bliki/ContinuousDelivery.html DevOPS – Development + Operations - https://dzone.com/articles/the-role- of-unit-tests-in-test-automation

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

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

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 emails 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

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

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)

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

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

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

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 http://bettercodingtools.com/message-broker-test-coverage-using-tracing/ Using “instrumentation” Provides coverage for ESQL, Messageflows, Java and XSL http://bettercodingtools.com/message-broker-test-coverage/

MB-Precise benefits (cont) Currently has 310+ rules for WMB/IIB http://bettercodingtools.com/mb-rules-complete/ Currently has 20+ rules for DP (XSL)

More features Diagram generation: http://bettercodingtools.com/gallery-images/

Find out more Our website contains more information: http://bettercodingtools.com/ Demos, tutorials and presentations: http://bettercodingtools.com/gallery-videos/ You can contact us via our website http://bettercodingtools.com/contact/ Or via email Richard@bettercodingtools.com