{"id":23210,"date":"2023-08-18T21:02:27","date_gmt":"2023-08-18T11:02:27","guid":{"rendered":"https:\/\/adactin.com\/?p=23210"},"modified":"2023-08-18T21:02:27","modified_gmt":"2023-08-18T11:02:27","slug":"software-dev-blog","status":"publish","type":"post","link":"https:\/\/www.onlinedigitalcompany.com\/adactin\/software-dev-blog\/","title":{"rendered":"Software Dev Blog"},"content":{"rendered":"\n

Quite often we come across situations in the software development industry where we ensure that every single feature is tested before a release, but we still find something broken once the application is released into production. It can be either due to a couple of testers not creating all the test cases required, or missing the execution of a couple of existing tests during the regression cycle. This can be either a manually tested regression suite or an automated suite, we still run into the same problem, wherein the so-called test coverage is 100%, but we still find something broken once released.<\/p>\n\n\n\n

To ensure the entire application code has been covered as part of the testing process we can use the Clover code coverage tool. In this blog, I will be focusing on using Maven as the build tool and will be using a sample java spring application. So this is how the tool works.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Basically when the project is built, all the classes in the project get instrumented and these instrumented classes get packaged as part of the jar\/war file. To keep it simple, you can think of instrumentation as the Java classes being slightly modified, to track which lines of the class are being traversed when the application is used. Along with the instrumentation, the clover.db registry is created, where the project structure and the details of all the classes are stored.<\/p>\n\n\n\n

Now when you deploy this jar\/war file, the instrumented classes are deployed and the clover coverage recorder files are created. These .db files store the coverage information of which lines of code have been traversed when the application is in use.<\/p>\n\n\n\n

Now let us try it out on a sample application<\/p>\n\n\n\n

You can download any public sample application available on Github to try it out. I have downloaded this publicly available application from Github:\u00a0https:\/\/github.com\/joakim666\/spring-boot-spring-loaded-java8-example<\/a><\/p>\n\n\n\n

<\/p>\n\n\n\n

Steps:<\/p>\n\n\n\n

  1. Add the below profiles section in the pom.xml of this project.
    <\/li><\/ol>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    2. Build the application using the below command:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Once the build is done, you will find that an \u2018instrument\u2019 folder is created under your project and a \u2018clover.db\u2019 registry has been created. If you navigate into the classes folder (\u2018target\\classes\\hello\u2019) you will also find that there are additional .class files created with _CLR4 appended. These are the instrumented classes.<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    3.Run the application using the below command from the project directory:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Once the application is started, you can see that there are additional clover .db files created having names such as \u2018clover.db.liverec\u2019, \u2018clover.db6ivvjj_lkzicfyg\u2019 etc. These files are used to store the details of which lines of code have been traversed in each of the classes when the user is using the application.<\/p>\n\n\n\n

    4. Now let us generate a Clover report before we use the application and see what the coverage looks like and what lines of code are covered. To generate a clover report we will first need the clover jar file. You can copy the clover jar from the maven repository ({your home directory}\\.m2\\repository\\org\\openclover\\clover\\4.4.1\\clover-4.4.1.jar) and place it in your project directory. Once done you can run the below command.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    5. You can now open \u2018dashboard.html\u2019 under the \u2018CloverReports\u2019 folder to view the coverage details. Here you can see that currently there would be only about 30\u201335% coverage, which would mainly be the code that was used to bring up the application. You can also see that the methods responsible for displaying the home page, login page etc have not been used yet (Highlighted in red).<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    6. Now navigate to the home page of the application using the URL\u00a0http:\/\/localhost:8080\/home<\/a>. On the home screen click on the \u2018here<\/a>\u2019 link that is displayed. This will take you to the login screen. Once done, generate the report once again using the command in step 4 and view the coverage information in the Clover report.<\/p>\n\n\n\n

    You can now see that the coverage percentage has increased from 30% to around 65%. Also, the \u2018home\u2019 method responsible for displaying the home screen, and the \u2018login\u2019 method responsible for displaying the login screen are shown as covered in your Clover report.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    And this is how you can ensure that 100% of all your code has been tested, either manually or through automated capabilities, before releasing an application to the production environment without any margin for human error.<\/p>\n\n\n\n

    Clover also provides advanced capabilities for excluding specific packages, classes and sections of code such as the catch blocks. It also provides capabilities for capturing coverage in a distributed infrastructure as well.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Quite often we come across situations in the software development industry where we ensure that every single feature is tested before a release, but we still find something broken once the application is released into production. It can be either due to a couple of testers not creating all the test cases required, or missing … Continue reading Software Dev Blog<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[],"class_list":["post-23210","post","type-post","status-publish","format-standard","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/posts\/23210","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/comments?post=23210"}],"version-history":[{"count":0,"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/posts\/23210\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/media?parent=23210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/categories?post=23210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.onlinedigitalcompany.com\/adactin\/wp-json\/wp\/v2\/tags?post=23210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}