Makefile: compile all *.cpp files and create individual executables

This is an example of a Makefile the compiles all *.cpp files in the current folder and turns them all into individual executables

CC=g++
CFLAGS=-c -Wall
SOURCES = $(wildcard *.cpp)
EXECS = $(SOURCES:%.cpp=%)

all: $(EXECS)

clean:
	rm $(EXECS)

Tested on OSX 10.14 and GNU Make 3.81

Checkstyle CustomImportOrderRules

This is a nice tool to get a unified look for all the imports of a codebase. A custom import order rule is set in the TreeWalker module (Checker->TreeWalker). Eg.


<module name="Checker">
  <property name="severity" value="warning">
  <module name="TreeWalker">
    <module name="CustomImportOrder">
      <property name="customImportOrderRules" value="
STANDARD_JAVA_PACKAGE###THIRD_PARTY_PACKAGE###SPECIAL_IMPORT
###SAME_PACKAGE(3)###STATIC">
      <property name="standardPackageRegExp" value="java\.|javax\."/>
      <property name="thirdPartyPackageRegExp" value="org\.|com\."/>
      <property name="specialImportsRegExp" value="se.my.packages*"/>
...      

In the example above then following rules apply:
customImportOrderRules – this sets the order of the imports. Here the order is set as:

  1. STANDARD_JAVA_PACKAGE (Eg. imports that contains the words “java.” or “javax.”)
  2. THIRD_PARTY_PACKAGE (Eg. imports that contains the words “org.” or “com.”)
  3. SPECIAL_IMPORT (Eg. imports that starts with the text “se.my.packages”)
  4. SAME_PACKAGE(3). Packages in the same module. The number defines then depth were a package should be considered “the same”. Eg. a 3 means that all packages that share the 3 first modules are considered the same, eg. “java.util.concurrent.AbstractExecutorService” and “java.util.concurrent.locks.LockSupport” are considered the same as the share “java.util.concurrent”
  5. STATIC. Static packages (packages that have the static keyword in them, eg. import static se.my.package…)

standardPackageRegExp – this defines what is to be considered a “standard package” in the project. Use regular expression to match import strings that should be included. Correlates with STANDARD_JAVA_PACKAGE in “customImportOrderRules” property
thirdPartyPackageRegExp – defines the third party packages in the project. Use regular expression to match import strings that should be included. Correlates with THIRD_PARTY_PACKAGE in “customImportOrderRules” property
specialImportsRegExp – defines the special packages. Use regular expression to match import strings that should be included. Correlates with SPECIAL_IMPORTS in “customImportOrderRules” property

Rules are evaluated in priority order, so an import can only match one rule:

  1. STATIC
  2. SAME_PACKAGE
  3. STANDARD_JAVA_PACKAGE and SPECIAL_IMPORTS – longest match wins
  4. THIRD_PACKAGE

Custom import order can help to unify your code but it is quite a handfull to configure. This will hopefully help you configure yours

Tested with Checkstyle v8.14

Read the application log when testing your Spring application

From time to time I need to check so that a function correctly logs error messages to the application log. Here is one solution using Logback in a Spring application

import ch.qos.logback.classic.Logger;
import ch.qos.logback.classic.spi.LoggingEvent;
import ch.qos.logback.core.Appender;

import org.mockito.ArgumentMatcher;

import org.slf4j.LoggerFactory;

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

@Test
public void shouldWriteErrorMessageToLog() {
  Logger l = (Logger) LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME);
  Appender mockAppender = mock(Appender.class);
  l.addAppender(mockAppender);

  /*
   * Call function that is expected to write to the application log
   */

  verify(mockAppender).doAppend(argThat(new ArgumentMatcher() {
    @Override
    public boolean matches(final Object argument) {
      return ((LoggingEvent)argument).getMessage().contains("FooBar");
    }
  }));
}

Tested with Spring Boot v2.2.4 and TestNG v6.11