A commitment to unit testing results in easier to maintain code in the long term

The benefits of religiously following a strict Test Driven Development (TDD) approach (always write tests first before code) is a hotly debated topic. No experienced developer would ignore the fact that testing is essential, but there are debatable pros and cons for whether writing unit tests before, during or after has the most benefit.

If your team has a commitment to unit testing there is valuable side benefit to your code quality that can arise by itself but is usually encouraged by more experienced development teams. Overly complex code that doesn’t have a clear or single responsibility, is tightly coupled with other code and/of is excessively long, is hard to test. Complex code is hard to understand and maintain, it’s usually also the source for more defects compared with simpler and easier to understand code. Effective teams always look for areas where they can become more efficient and make their lives easier, and aiming to develop simpler code to make it easier to test brings these additional benefits with it.

By adopting a mindset that code should be developed and structured in a simpler way so that it is easier to test, you instantly gain from the benefits of simpler code that’s easier to maintain. Win-win all round.

Building a Maven based Spring Boot app with multiple app classes with main() methods

I have a Maven based Spring Boot project with 2 Application classes. One is my main Spring Boot app, the other is a standalone example app. When attempting to build with ‘mvn package’ I get this error:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.6.4:repackage (repackage) on project xample-client: Execution repackage of goal org.springframework.boot:spring-boot-maven-plugin:2.6.4:repackage failed: Unable to find a single main class from the following candidates [kh.aprs.botexample.APRSISBotExampleApplication, kh.aprs.clientexample.APRSISClientExampleApplication]

The 2 apps listed are my 2 apps, but only APRSISBotExampleApplication is the one I want to get packaged, so I need to tell Maven which is the the main app. This is configured with the <start-class> property, configured in a properties section like this:

<properties>
 <start-class>your.package.YourApplication</start-class>
</properties>

This is described here.

Calculating elapsed minutes between LocalDateTime instances

There’s many ways to this, like getting epoch millis, calculating the difference and then converting back into the units you need. With java.time apis and java.time.temporal.ChronoUnit you can calculate the difference between 2 LocalDateTime instances easily in one step with:

long elapsedMins = ChronoUnit.MINUTES.between(start, end);

I was looking for a refresher on how to do this and found my own post from 3 years ago in a Google search here (funny when that happens).

Refresher: serverless framework local development workflow

It’s been a while since I’ve written any notes about the Serverless framework, so here’s a few notes as a refresher on typical steps I use for local development.

As a reminder to self, regions I typically deploy to are:

  • us-west-1 : SF
  • us-west-2: Oregon
  • eu-west-2: London

AWS regions are listed here.

To deploy:

serverless deploy --region eu-west-2

To invoke local:

serverless invoke local --function functionName

To invoke remotely:

serverless invoke --function functionName --region eu-west-2

To check logs from last invoke:

serverless logs --function functionName --region eu-west-2