{"id":835,"date":"2020-03-30T06:00:00","date_gmt":"2020-03-30T06:00:00","guid":{"rendered":"http:\/\/bullyrooks.com\/index.php\/2020\/03\/30\/simple-spring-boot-service-to-kubernetes-application-step-6-c52f5247ba20\/"},"modified":"2021-02-04T01:49:09","modified_gmt":"2021-02-04T01:49:09","slug":"simple-spring-boot-service-to-kubernetes-application-step-6-c52f5247ba20","status":"publish","type":"post","link":"https:\/\/bullyrooks.com\/index.php\/2020\/03\/30\/simple-spring-boot-service-to-kubernetes-application-step-6-c52f5247ba20\/","title":{"rendered":"Documentation and Code Coverage"},"content":{"rendered":"\n

Before we move on to getting our service ready for deployment we need to do a little more housecleaning. Sometimes these tasks get de-prioritized so we might as well take care of it now, before we move on.<\/p>\n\n\n\n

Endpoint Documentation<\/h3>\n\n\n\n

Using OpenAPI is a powerful tool for documenting our REST endpoints. Documenting our endpoints reduces the amount of unplanned time we need to take from our priorities to support our users or clients of our service. Additionally, it can also be used to generate the clients<\/strong>, so that we don\u2019t have to build and maintain client libraries.<\/p>\n\n\n\n

First we need to add the dependencies to our maven pom file.<\/p>\n\n\n\n

<properties>\n   ...\n   <springdoc-openapi-core.version>1.1.49<\/springdoc-openapi-core.version>\n<\/properties><\/code><\/pre>\n\n\n\n
<dependencies>\n...\n   <!-- documentation -->\n   <dependency>\n      <groupId>org.springdoc<\/groupId>\n      <artifactId>springdoc-openapi-ui<\/artifactId>\n      <version>${springdoc-openapi-core.version}<\/version>\n   <\/dependency>\n...\n<\/dependencies><\/code><\/pre>\n\n\n\n
Restart our application and go to http:\/\/localhost:10000\/swagger-ui\/<\/a><\/code>. You should see the swagger ui and you can see our endpoint. You can also confirm on the CustomerDTO <\/code>schema that the validation requirements are documented.<\/p>\n\n\n\n
Code Coverage<\/h3>\n\n\n\n
We really need to be aware of how our code is evolving. One particularly useful metric is code coverage. We\u2019ll be following this example<\/a> to configure our project to generate code coverage reports via jacoco.<\/p>\n\n\n\n
Add this configuration to the pom.xml<\/code> file:<\/p>\n\n\n\n
<properties>\n   ...\n   <jacoco-maven-plugin.version>0.8.5<\/jacoco-maven-plugin.version>\n<\/properties><\/code><\/pre>\n\n\n\n
<build>\n   <plugins>\n      ...\n      <plugin>\n         <groupId>org.jacoco<\/groupId>\n         <artifactId>jacoco-maven-plugin<\/artifactId>\n         <version>${jacoco-maven-plugin.version}<\/version>\n         <executions>\n            <execution>\n               <goals>\n                  <goal>prepare-agent<\/goal>\n               <\/goals>\n            <\/execution>\n            <execution>\n               <id>report<\/id>\n               <phase>prepare-package<\/phase>\n               <goals>\n                  <goal>report<\/goal>\n               <\/goals>\n            <\/execution>\n         <\/executions>\n      <\/plugin>\n   <\/plugins>\n\n<\/build><\/code><\/pre>\n\n\n\n
And build the report with mvn clean test jacoco:report<\/code>. View the report at \/target\/site\/jacoco\/index.html<\/code>. Its should look something like this:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Which looks kind of bad, but its actually failing because of all of the generated Lombok code (as well as some classes we shouldn\u2019t be testing). Lets exclude that from the report. Finally, we see that the controller advice as well as the config <\/code>package are being analyzed. Lets move controller advice to config <\/code>and exclude the config <\/code>directory. Additionally, lets exclude the spring boot Application class and the exceptions from the jacoco-maven-plugin<\/code> maven plugin definition.<\/p>\n\n\n\n
<\/execution>\n   <\/executions>\n   <configuration>\n      <excludes>\n         <exclude>com\/brianrook\/medium\/customer\/config\/**\/*<\/exclude>\n         <exclude>com\/brianrook\/medium\/customer\/*Application*<\/exclude>\n         <exclude>com\/brianrook\/medium\/customer\/exception\/**\/*<\/exclude>\n      <\/excludes>\n   <\/configuration>\n<\/plugin><\/code><\/pre>\n\n\n\n
Rerunning our report looks much better, but we can see two issues. One is that the code generated by mapstruct has some untested paths. We can and should write tests for these because mapping classes are high risk. If you look at the report closely, you can see that we don\u2019t have test cases around null input. These tests are easily written.<\/p>\n\n\n\n
package com.brianrook.medium.customer.controller.mapper;\n\nimport org.junit.jupiter.api.Test;\n\nimport static org.assertj.core.api.Assertions.assertThat<\/em>;\n\npublic class CustomerDTOMapperTest {\n    @Test\n    public void testNullCustomer(){\nassertThat<\/em>(CustomerDTOMapper.INSTANCE<\/em>.customerToCustomerDTO(null)).isNull();\n    }\n    @Test\n    public void testNullCustomerDTO(){\nassertThat<\/em>(CustomerDTOMapper.INSTANCE<\/em>.customerDTOToCustomer(null)).isNull();\n    }\n}<\/code><\/pre>\n\n\n\n
package com.brianrook.medium.customer.dao.mapper;\n\nimport org.junit.jupiter.api.Test;\n\nimport static org.assertj.core.api.Assertions.assertThat<\/em>;\n\npublic class CustomerEntityMapperTest {\n    @Test\n    public void testNullCustomer(){\nassertThat<\/em>(CustomerEntityMapper.INSTANCE<\/em>.customerToCustomerEntity(null)).isNull();\n    }\n    @Test\n    public void testNullCustomerDTO(){\nassertThat<\/em>(CustomerEntityMapper.INSTANCE<\/em>.customerEntityToCustomer(null)).isNull();\n    }\n}<\/code><\/pre>\n\n\n\n
More importantly, we can see that the service class has an untested exception path. We could easily write a unit test here that mocks the DAO and throws an exception. I would say: please don\u2019t do that! This is a path that we added for a specific behavior, so lets create a behavior test. Add this additional test to CustomerControllerTest<\/code>:<\/p>\n\n\n\n
@Test\npublic void testAddCustomerConflict() throws URISyntaxException\n{\n    CustomerEntity savedRecord = CustomerEntity.builder<\/em>()\n            .firstName(\"test\")\n            .lastName(\"user\")\n            .email(\"test.user@test.com\")\n            .phoneNumber(\"(123)654-7890\")\n            .build();\n    customerDAO.save(savedRecord);\n\n    RestTemplate restTemplate = new RestTemplate();\n    String baseUrl = \"http:\/\/localhost:\"+randomServerPort+customerPath;\n    URI uri = new URI(baseUrl);\n    CustomerDTO customerDTO = CustomerDTO.builder<\/em>()\n            .firstName(savedRecord.getFirstName())\n            .lastName(savedRecord.getLastName())\n            .email(savedRecord.getEmail())\n            .phoneNumber(savedRecord.getPhoneNumber())\n            .build();\n\n    HttpHeaders headers = new HttpHeaders();\n    headers.set(HttpHeaders.CONTENT_TYPE<\/em>, MediaType.APPLICATION_JSON_VALUE<\/em>);\n\n    HttpEntity<CustomerDTO> request = new HttpEntity<>(customerDTO, headers);\n\n    try {\n        ResponseEntity<CustomerDTO> result = restTemplate.postForEntity(uri, request, CustomerDTO.class);\n\n    }catch (HttpServerErrorException e) {\n        \/\/Verify request failed\n        Assertions.assertEquals<\/em>(500, e.getRawStatusCode());\n    }\n}<\/code><\/pre>\n\n\n\n
Rerun the report. We should have 100% coverage now. The best part is it only took 3 test classes and 6 tests to get there.<\/p>\n\n\n\n
Build and Commit<\/h3>\n\n\n\n
git checkout -b coverage\nmvn clean install\ngit add .\ngit commit -m \"OpenAPI docs and code coverage\"\ngit push --set-upstream origin coverage\ngit checkout master\ngit merge coverage\ngit push<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
\nBefore we move on to getting our service ready for deployment we…\n<\/div>\n
Continue reading “Documentation and Code Coverage”<\/span>…<\/a><\/div>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[70,71,68,42,43,69],"course":[40],"class_list":["post-835","post","type-post","status-publish","format-standard","hentry","category-software-development","tag-code-coverage","tag-jacoco","tag-openapi","tag-spring","tag-spring-boot","tag-swagger","course-spring-with-kubernetes","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":1447,"url":"https:\/\/bullyrooks.com\/index.php\/2023\/05\/14\/unit-tests-vs-component-tests-which-ones-better-for-software-quality\/","url_meta":{"origin":835,"position":0},"title":"Unit Tests vs. Component Tests: Which One’s Better for Software Quality?","author":"Bullyrook","date":"May 14, 2023","format":false,"excerpt":"Dive into the good and bad of unit tests and component tests in software development. Find out how to get the best of both worlds for top-notch code quality.","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1264,"url":"https:\/\/bullyrooks.com\/index.php\/2022\/02\/13\/kube-cloud-pt3-health-indicators\/","url_meta":{"origin":835,"position":1},"title":"Kube Cloud Pt3 | Health Indicators","author":"Bullyrook","date":"February 13, 2022","format":false,"excerpt":"Spring offers a way to tell if your services and their dependent resources are up and healthy. Kubernetes can leverage this functionality via their liveness and readiness probes to report if pods are available to service requests. In this session, we're going to enable and connect those health checks. Enable\u2026","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/02\/image-4.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/02\/image-4.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/02\/image-4.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":1133,"url":"https:\/\/bullyrooks.com\/index.php\/2021\/07\/25\/confirming-the-continuous-deployment-pipeline\/","url_meta":{"origin":835,"position":2},"title":"Confirming the Continuous Deployment Pipeline","author":"Bullyrook","date":"July 25, 2021","format":false,"excerpt":"Lets verify that changes to our application will be automatically available when they're pushed up. Update the Application Let's start a new branch $ git checkout -b \"greeting-change\" Now update our service to return a different greeting: @Component public class HelloWorldService { public HelloWorld helloWorld(String name) { return HelloWorld.builder() .response(\"G'Day,\u2026","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2021\/07\/image-48.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2021\/07\/image-48.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2021\/07\/image-48.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2021\/07\/image-48.png?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":820,"url":"https:\/\/bullyrooks.com\/index.php\/2020\/03\/30\/simple-spring-boot-service-to-kubernetes-application-step-17-3867eb38d8f1\/","url_meta":{"origin":835,"position":3},"title":"Containerizing our UI","author":"Bullyrook","date":"March 30, 2020","format":false,"excerpt":"We\u2019ve got a simple page that calls one of our endpoints working. Let\u2019s go ahead an containerize it so that we can deploy it into our k8s environment in future steps. Build the Dockerfile I\u2019m following the process laid out here, with some minor differences. Create a Dockerfile # Stage\u2026","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":828,"url":"https:\/\/bullyrooks.com\/index.php\/2020\/03\/30\/simple-spring-boot-service-to-kubernetes-application-step-4-dba10da3d834\/","url_meta":{"origin":835,"position":4},"title":"Create a REST Controller","author":"Bullyrook","date":"March 30, 2020","format":false,"excerpt":"In this article we\u2019re going to take the service layer we created in the last step and add a REST interface to it. We\u2019re going to follow the hexagonal design principles we previously discussed and add a functional or component test and explain how those test work and why they\u2019re\u2026","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":819,"url":"https:\/\/bullyrooks.com\/index.php\/2020\/03\/30\/simple-spring-boot-service-to-kubernetes-application-step-3-f03bdfe30ceb\/","url_meta":{"origin":835,"position":5},"title":"Building a Service Layer","author":"Bullyrook","date":"March 30, 2020","format":false,"excerpt":"In this stage we\u2019re going to build out the service or logical layer of our microservice. I\u2019ll explain adapter and port or hexagonal architecture and covering the usage of mapstruct. Service Design Ports and adapter or hexagonal design is a well discussed concept, so I\u2019m not going to go into\u2026","rel":"","context":"In "Software Development"","block_context":{"text":"Software Development","link":"https:\/\/bullyrooks.com\/index.php\/category\/software-development\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/posts\/835","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/comments?post=835"}],"version-history":[{"count":4,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/posts\/835\/revisions"}],"predecessor-version":[{"id":887,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/posts\/835\/revisions\/887"}],"wp:attachment":[{"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/media?parent=835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/categories?post=835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/tags?post=835"},{"taxonomy":"course","embeddable":true,"href":"https:\/\/bullyrooks.com\/index.php\/wp-json\/wp\/v2\/course?post=835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}