Sprint 5 Retrospective Blog

For this week’s sprint, I’ve spent most of the time looking into a way to automatically increment the version number (based on semantic versioning) every time we make changes. Currently there is a reference to the version number in 4 different places: The Procfile used by Heroku, the build.gradle file, the Java configuration file for Swagger, and the README Markdown file. To do this, I’ve been looking at different Gradle plugins that could do this automatically. There seem to be many different options available, but there doesn’t seem to be one that completely fits what I’m trying to do. I think that the fact that some of these files simply have the version number hard coded in is causing this issue. It would be simpler if the version number was located in one place (maybe a version.properties file) where all of the other files simply reference that file to do what they need to do with the version number.

While it’s not exactly an high priority task, given that there doesn’t seem to be many more changes needed to be made to the project at the time, it’s important to automate the version incrementation now in case the project needs to be updated in the future. It’s definitely not a good idea to keep it the way it is, as having the change the version number in multiple locations could potentially break something if one of them is forgotten. For example, we already ran into an issue where Heroku couldn’t find the jar file created because the version number hadn’t been updated in the gradle.build file but it had been in the Procfile. This caused the jar file that was created to have the wrong name, so Heroku couldn’t find it.

Also, another thing that I want to start looking into is to add unit tests using JUnit, as it’s something that I’ve neglected to do but definitely want to get done before the semester ends. That would include some basic unit tests for each class to make sure their methods are working properly but also some Spring Boot specific tests. For example, I should be able to create tests for each endpoint to confirm that they’re working properly, perhaps using some of the techniques learned from previous coursework such as mocks. Spring Boot appears to have a wide variety of auto-configured annotations that could potentially be useful for creating these tests. For example, the annotation “@RestClientTest” disables full automatic configuration and instead only applies the configuration that is relevant to REST client tests. This ensures that Jackson and GSON support is auto-configured.

In conclusion, I’m hoping to finish up with the automatic versioning as well as added necessary tests to the project by the end of the last sprint and before the presentation. I definitely don’t want to leave the project without adding any tests as that’s bad practice. In any future projects I’ll need to make sure not to neglect creating useful tests but I also want to avoid creating useless tests that were made just to have tests in the project.

Sources:
https://www.baeldung.com/spring-boot-testing
https://www.baeldung.com/restclienttest-in-spring-boot
https://github.com/davideas/GrabVer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: