DEV Community: Carlos Monteiro

Basic tip to improve the general quality of your tests and become a better developer

Carlos Monteiro — Sat, 31 May 2025 02:16:32 +0000

Author's message

Hello, developer community, I wrote this post based on insights gained over the years. This isn't something I’ve gleaned from books written by developers with decades of experience, so please don’t take these as rules. Use them if you agree, and share your ideas with me so I can learn from them.

Why are we testing?

Tests ensure that an application is working as expected. With coded tests, we can prevent anyone from changing this.

What do we as developers look for when testing?

When we are developing something, we know exactly what we expect as a result of the piece of code we have written. We have a clear understanding of it, what is happening, and what needs to happen in each possible scenario.

Our role is to be the guardian of functionality; no one can change the behavior we have gracefully programmed. Expected or unexpected changes must break the tests.

Are our tests good?

Let's start with two spring services:

The purpose of this first class is to provide the current offset date time using the given zone id.

@Service
public final class DateService {
 public OffsetDateTime getCurrentDate(final ZoneId zoneId) {
     return OffsetDateTime.now(zoneId);
 }
}

This other class will be called by the controller layer and will use the DateService class to generate a date and before returning, it will format the result obtained.

@Service
public final class UtilityService {

    private final DateService dateGeneratorService;

    public static final String DEFAULT = "uuuu-MM-dd'T'HH:mmXXXXX";

    public UtilityService(final DateService dateGeneratorService) {
        this.dateGeneratorService = dateGeneratorService;
    }

    public String getNowDate(final String offsetId, final String format) {
        final OffsetDateTime dateTime = dateGeneratorService.getCurrentDate(
                Objects.requireNonNullElse(offsetId, ZoneOffset.UTC.getId())
        );

        return dateTime.format(DateTimeFormatter.ofPattern(
                Objects.requireNonNullElse(format, DEFAULT)
        ));
    }
}

How about the test class?

@ExtendWith(MockitoExtension.class)
public class UtilityServiceTest {

    @Mock
    private DateService dateService;

    @InjectMocks
    private UtilityService utilityService;

    @Test
    public void shouldGetNowDateWithProvidedParameters() {
        when(dateService.getCurrentDate(any())).thenReturn(OffsetDateTime.now());

        final String result = utilityService.getNowDate(ZoneOffset.UTC, "uuuu-MM-dd'T'HH:mmXXXXX");

        assertNotNull(result);
    }
}

The above test is a common one. It will cover all lines (without considering all situations), check that the date service is being called (since the test is not throwing a NullPointerException), and return a result.

The test is working!

✓ shouldGetNowDateWithProvidedParameters()

What will happen if another developer tries to make changes during their daily routine? Let's exercise this:

[Scenario 1] Accidentally changed the parameter offsetId by format (since both are strings).

    public String getNowDate(final String offsetId, final String format) {
        final OffsetDateTime dateTime = dateGeneratorService.getCurrentDate(
                // BEFORE
                Objects.requireNonNullElse(offsetId, ZoneOffset.UTC.getId())
                // NOW
                Objects.requireNonNullElse(format, ZoneOffset.UTC.getId())
        );

        return dateTime.format(DateTimeFormatter.ofPattern(
                Objects.requireNonNullElse(format, DEFAULT)
        ));
    }

The test is working!

✓ shouldGetNowDateWithProvidedParameters()

[Scenario 2] Consider that there is no reason to treat the null cases, since there is no reason to call API without one of the parameters.

    public String getNowDate(final String offsetId, final String format) {
        // BEFORE
        final OffsetDateTime dateTime = dateGeneratorService.getCurrentDate(
                Objects.requireNonNullElse(offsetId, ZoneOffset.UTC.getId())
        );
        // NOW
        final OffsetDateTime dateTime = dateGeneratorService.getCurrentDate(offsetId)
        );

        return dateTime.format(DateTimeFormatter.ofPattern(
                Objects.requireNonNullElse(format, DEFAULT)
        ));
    }

The test is working!

✓ shouldGetNowDateWithProvidedParameters()

[Scenario 3] Decides to change the default pattern.

    // BEFORE
    public static final String DEFAULT = "uuuu-MM-dd'T'HH:mmXXXXX";
    // NOW
    public static final String DEFAULT = "uuuu-MM-dd'T";

    public String getNowDate(final String offsetId, final String format) {
        final OffsetDateTime dateTime = dateGeneratorService.getCurrentDate(
                Objects.requireNonNullElse(offsetId, ZoneOffset.UTC.getId())
        );

        return dateTime.format(DateTimeFormatter.ofPattern(
                Objects.requireNonNullElse(format, DEFAULT)
        ));
    }

The test is working!

✓ shouldGetNowDateWithProvidedParameters()

How can we solve this?

The test class below works, but it is very inefficient.

@ExtendWith(MockitoExtension.class)
public class UtilityServiceTest {

    @Mock
    private DateService dateService;

    @InjectMocks
    private UtilityService utilityService;

    @Test
    public void shouldGetNowDateWithProvidedParameters() {
        when(dateService.getCurrentDate(any())).thenReturn(OffsetDateTime.now());

        final String result = utilityService.getNowDate("Z", "uuuu-MM-dd'T'HH:mmXXXXX");

        assertNotNull(result);
    }
}

Let's create a new version!

Changes to prevent [Scenario 1].

    @Test
    public void shouldGetNowDateWithProvidedParameters() {
        final String anyOffsetId = "Z";
        final String anyFormat = "uuuu-MM-dd'T'HH:mmXXXXX";

        when(dateService.getCurrentDate(anyOffsetId)).thenReturn(OffsetDateTime.now());

        //act
        final String result = utilityService.getNowDate(anyOffsetId, anyFormat);

        assertNotNull(result);
    }

✘ shouldGetNowDateWithProvidedParameters

We are not expecting to get the current date with any value; we know that the first parameter of the getNowDate method represents the offset that needs to be used to call the DateService class.

Changes to prevent [Scenario 2].

    @Test
    public void shouldUseUTCOffsetWhenGetNowDateIsCalledWithNull() {
        final String anyFormat = "uuuu-MM-dd'T'HH:mmXXXXX";

        when(dateService.getCurrentDate(ZoneOffset.UTC.getId())).thenReturn(OffsetDateTime.now());

        //act
        final String result = utilityService.getNowDate(null, anyFormat);

        assertNotNull(result);
    }

✘ shouldGetNowDateWithProvidedParameters

Different scenarios need to be covered, the exact expectations need to be validated.

Changes to prevent [Scenario 3].

    @Test
    public void shouldUseDefaultPatternWhenGetNowDateIsCallWithNull() {
        final String anyOffsetId = "Z";
        final OffsetDateTime now = OffsetDateTime.now();

        when(dateService.getCurrentDate(anyOffsetId)).thenReturn(now);

        //act
        final String result = utilityService.getNowDate(anyOffsetId, null);

        assertEquals(
                result,
                now.format(DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mmXXXXX")),
                "The generated date string must have the pattern uuuu-MM-dd'T'HH:mmXXXXX"
        );
    }

✘ shouldGetNowDateWithProvidedParameters

Different scenarios need to be covered, the exact expectations need to be validated.

Final Version

@ExtendWith(MockitoExtension.class)
public class UtilityServiceTest {

    @Mock
    private DateService dateService;

    @InjectMocks
    private UtilityService utilityService;

    @Test
    public void shouldGetNowDateWithProvidedParameters() {
        when(dateService.getCurrentDate(any())).thenReturn(OffsetDateTime.now());

        //act
        final String result = utilityService.getNowDate("Z", "uuuu-MM-dd'T'HH:mmXXXXX");

        assertNotNull(result);
    }

    /**
     * [Scenario 1]
     *
     * Accidentally changed the parameter offsetId by format (since both are strings).
     */
    @Test
    public void shouldGetNowDateWithProvidedParameters_Scenario_1() {
        final String anyOffsetId = "Z";
        final String anyFormat = "uuuu-MM-dd'T'HH:mmXXXXX";

        when(dateService.getCurrentDate(anyOffsetId)).thenReturn(OffsetDateTime.now());

        //act
        final String result = utilityService.getNowDate(anyOffsetId, anyFormat);

        assertNotNull(result);
    }

    /**
     * [Scenario 2]
     *
     * Consider that there is no reason to treat the null cases, since there is no reason to call API without one of the parameters.
     */
    @Test
    public void shouldUseUTCOffsetWhenGetNowDateIsCalledWithNull() {
        final String anyFormat = "uuuu-MM-dd'T'HH:mmXXXXX";

        when(dateService.getCurrentDate(ZoneOffset.UTC.getId())).thenReturn(OffsetDateTime.now());

        //act
        final String result = utilityService.getNowDate(null, anyFormat);

        assertNotNull(result);
    }

    /**
     * [Scenario 3]
     *
     * Decides to change the default pattern.
     */
    @Test
    public void shouldUseDefaultPatternWhenGetNowDateIsCallWithNull() {
        final String anyOffsetId = "Z";
        final OffsetDateTime now = OffsetDateTime.now();

        when(dateService.getCurrentDate(anyOffsetId)).thenReturn(now);

        //act
        final String result = utilityService.getNowDate(anyOffsetId, null);

        assertEquals(
                result,
                now.format(DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mmXXXXX")),
                "The generated date string must have the pattern uuuu-MM-dd'T'HH:mmXXXXX"
        );
    }
}

Conclusion

The examples and refactorings we have made show us that even the best tool can be inefficient if not used well. Avoid partial checks. Every line must be considered, every scenario, and every expectation must be met. This will strengthen your tests and make you a better developer.

Check the source code on github.com.

Before you go!

Follow for more ;)
Suggest new topics
Use the comments section to discuss the feature and >comment on real-world use cases to help others understand >its usage

How to create your logging system using SLF4J

Carlos Monteiro — Sat, 18 May 2024 05:17:21 +0000

As a software developer, it's not always possible to dive deep into the language you're working with, and sometimes it's difficult to find situations where you need to use advanced or non-trivial features. It's easy to use a magic framework, the hard part is having the necessary knowledge to create it. For this reason, I created the tag #javaunderthehood to gather this content and help other people understand how this magic happens. Feel free to join me with an interesting new topic.

Do you know what is SLF4J, LOG4J, Logbook or any other variation?

SLF4J is the acronym for Simple Logging Facade for Java, this library provides an interface for various logging frameworks.

In other words, SLF4J provides an interface for anyone who wants to create their own version, allowing you to use a common interface to register the logs of your application. When desired, you can replace the final output (such as a console log) with any different implementation. You can write your logs to a console, file, or database, or send them via email to one of the developers on the team, who will be responsible for writing a letter with the logs and sending it to you.

Knowing it, have you ever seen the line below in any project?

private static final Logger LOGGER = LoggerFactory.getLogger(Main.class);

Both Logger and LoggerFactory are classes of this service. To be able to use them, you only need to add the below dependency to your project.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.13</version>
</dependency>

By adding this dependency, you can create the logging structure of the application. But what will happen if you try to run only with this dependency?

As you can see in the above image, the app indicates that you don't have any log provider. Here, you can introduce LOG4J or Logbook, which are providers for this service. However, we don't want them; we want our version because 4 hours of development is better than 23 years of history.

After this brief explanation, let's implement a provider for the SLF4J api

As the first step, create a folder called provider in the root directory of your project, this folder will contain a maven .pom file and the source code of this new provider implementation.

Inside the .pom file, let's add the required dependency.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.13</version>
</dependency>

The most important class to keep in mind is the SLF4JServiceProvider, which is the interface, the service, for which we are creating a provider. For an in-depth understanding of what we are doing here, you can read the article Java Service Provider Interface (SPI), what is it and how to use it.

public interface SLF4JServiceProvider {
    ILoggerFactory getLoggerFactory();

    IMarkerFactory getMarkerFactory();

    MDCAdapter getMDCAdapter();

    String getRequestedApiVersion();

    void initialize();
}

Now you can create the provider, I'll call it SLF4JWorstProvider.

public class SLF4JWorstProvider implements SLF4JServiceProvider {

    private final String REQUESTED_API_VERSION = "2.0.13";

    private SLF4JWorkProviderLoggerFactory slf4JWorkProviderLoggerFactory;

    @Override
    public ILoggerFactory getLoggerFactory() {
        return slf4JWorkProviderLoggerFactory;
    }

    @Override
    public IMarkerFactory getMarkerFactory() {
        return null;
    }

    @Override
    public MDCAdapter getMDCAdapter() {
        return new NOPMDCAdapter();
    }

    @Override
    public String getRequestedApiVersion() {
        return REQUESTED_API_VERSION;
    }

    @Override
    public void initialize() {
        slf4JWorkProviderLoggerFactory = new SLF4JWorkProviderLoggerFactory();
    }
}

Overrides the getRequestedApiVersion() method to return the SLF4J version you depend on
Overrides the getLoggerFactory() method to return the factory implementation that creates the Logger object used to write logs.

The factory class needs to implement the ILoggerFactory interface, which has a method to return an implementation of another interface called Logger, responsible for writing logs in whatever place you want.

This is the ILoggerFactory interface.

public interface ILoggerFactory {
    Logger getLogger(String var1);
}

To be concise, I removed some of the code from the Logger interface.

public interface Logger {
    String ROOT_LOGGER_NAME = "ROOT";

    String getName();

    default LoggingEventBuilder makeLoggingEventBuilder(Level level) {
        return new DefaultLoggingEventBuilder(this, level);
    }

    @CheckReturnValue
    default LoggingEventBuilder atLevel(Level level) {
        return this.isEnabledForLevel(level) ? this.makeLoggingEventBuilder(level) : NOPLoggingEventBuilder.singleton();
    }

    default boolean isEnabledForLevel(Level level) {
        int levelInt = level.toInt();
        switch(levelInt) {
        case 0:
            return this.isTraceEnabled();
        case 10:
            return this.isDebugEnabled();
        case 20:
            return this.isInfoEnabled();
        case 30:
            return this.isWarnEnabled();
        case 40:
            return this.isErrorEnabled();
        default:
            throw new IllegalArgumentException("Level [" + level + "] not recognized.");
        }
    }

    boolean isInfoEnabled();

    void info(String var1);

    @CheckReturnValue
    default LoggingEventBuilder atInfo() {
        return this.isInfoEnabled() ? this.makeLoggingEventBuilder(Level.INFO) : NOPLoggingEventBuilder.singleton();
    }


    /.../
}

A possible implementation of both interfaces.

First, we have the factory.

public class SLF4JWorkProviderLoggerFactory implements ILoggerFactory {
    @Override
    public Logger getLogger(final String name) {
        return new SLF4JWorkProviderLogger(name);
    }
}

Lastly, we have the logger.

public class SLF4JWorkProviderLogger implements Logger {

    private final String name;

    public SLF4JWorkProviderLogger(final String name) {
        this.name = name;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public boolean isDebugEnabled() {
        return true;
    }

    @Override
    public void debug(String s) {
        logMessage(LevelEnum.DEBUG, s);
    }


    @Override
    public boolean isInfoEnabled() {
        return true;
    }

    @Override
    public void info(String s) {
        logMessage(LevelEnum.INFO, s);
    }

    private void logMessage(final LevelEnum level, final String message) {
        System.out.println(String.format("[%s][%s] %s (×͜×)", level, name, message));
    }
}

If you read article Java Service Provider Interface (SPI), what is it and how to use it you should know what to do so that LSF4J can load this new provider implementation. So, let's continue by creating a META-INF folder (inside the resources directory), with a services subfolder that contains a file whose name is the reference of the service class and its contents contain the implementation refence of our provider.

org.slf4j.spi.SLF4JServiceProvider

com.github.c4rlosmonteiro.sl4jworstprovider.SLF4JWorstProvider

At this point, we have the following project structure.

.
├── pom.xml
└── src
    └── main
        ├── java
        │   └── com
        │       └── github
        │           └── c4rlosmonteiro
        │               └── sl4jworstprovider
        │                   ├── internalcomponents
        │                   │   ├── LevelEnum.java
        │                   │   ├── SLF4JWorkProviderLoggerFactory.java
        │                   │   └── SLF4JWorkProviderLogger.java
        │                   └── SLF4JWorstProvider.java
        └── resources
            └── META-INF
                └── services
                    └── org.slf4j.spi.SLF4JServiceProvider

Finally, we can use this provider.

As you can see in the image, our logger records the logs below.

[INFO][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] Generating hello world messages! (×͜×)
[DEBUG][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] Generating hello world message for [Bob] (×͜×)
[INFO][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] :: Hello Bob! (×͜×)
[DEBUG][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] Generating hello world message for [Paul] (×͜×)
[INFO][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] :: Hello Paul! (×͜×)
[DEBUG][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] Generating hello world message for [Marcus] (×͜×)
[INFO][com.github.c4rlosmonteiro.slf4jworstprovideruser.Main] :: Hello Marcus! (×͜×)

You can test this version by adding the dependency below to your project.

<dependency>
  <groupId>com.github.c4rlosmonteiro</groupId>
  <artifactId>slf4j-worst-provider</artifactId>
  <version>1.0.0</version>
</dependency>

Check the source code on github.com.

Before you go!

Follow for more ;)
Suggest new topics
Use the comments section to discuss the feature and >comment on real-world use cases to help others understand >its usage

#javaunderthehood

Java Service Provider Interface (SPI), what is it and how to use it

Carlos Monteiro — Sat, 11 May 2024 05:47:19 +0000

As a software developer, it's not always possible to dive deep into the language you're working with, and sometimes it's difficult to find situations where you need to use advanced or non-trivial features. It's easy to use a magic framework, the hard part is having the necessary knowledge to create it. For this reason, I created the tag #javaunderthehood to gather this content and help other people understand how this magic happens. Feel free to join me with an interesting new topic.

What is the Service Provider Interface (SPI)?

Introduced in Java 6, the Service Provider Interface (SPI) provides the ability to extend application functionality by adding service implementations that can modify, replace or extend the original behavior of an application.

What is ServiceLoader java class?

The ServiceLoader class is the heart of this feature. What does the documentation say about the ServiceLoader class?

A facility to load implementations of a service.
A service is a well-known interface or class for which zero, one, or many service providers exist. A service provider (or just provider) is a class that implements or subclasses the well-known interface or class. A ServiceLoader is an object that locates and loads service providers deployed in the run time environment at a time of an application's choosing. Application code refers only to the service, not to service providers, and is assumed to be capable of choosing between multiple service providers (based on the functionality they expose through the service), and handling the possibility that no service providers are located.

In general, the service is an interface that you can use to implement your own provider. If this service is part of a dependency of your project and this dependency gives you the possibility, you can write your own provider that fits your needs and the library will be able to use it.

How to use it?

Let's start by creating our service, which will be an interface that will allow us to create implementations to proccess different types of images.

public interface ImageProcessorService {  
    String getType();  
    String process();  
}

Now we will create two implementations of it, which will be responsible for proccessing PNG and JPG images.

PNG

public final class PNGImageProcessorProvider implements ImageProcessorService {
  @Override
  public String getType() {
    return BasicImageType.PNG.name();
  }

  @Override
  public void process() {
    System.out.println("Processing PNG image");
  }
}

JPG

public class JPGImageProcessorProvider implements ImageProcessorService {
  @Override
  public String getType() {
    return BasicImageType.JPG.name();
  }

  @Override
  public void process() {
    System.out.println("Processing JPG image");
  }
}

In order for ServiceLoader to load our provider, we need to create a package called META-INF in our resource repository. This folder must contain a subfolder called services where we need to create a file with the reference to our service.

The appearance of our project looks something like this at the moment:

.
├── java
│   └── com
│       └── github
│           └── c4rlosmonteiro
│               └── imageprocessorservicespi
│                   ├── BasicImageType.java
│                   ├── provider
│                   │   ├── JPGImageProcessorProvider.java
│                   │   └── PNGImageProcessorProvider.java
│                   └── service
│                       └── ImageProcessorService.java
└── resources
    └── META-INF
        └── services
            └── com.github.c4rlosmonteiro.imageprocessorservicespi.service.ImageProcessorService

Now you need to modify the file com.github.c4rlosmonteiro.imageprocessorservicespi.service.ImageProcessorService and add the references to all the providers you want to load.

    com.github.c4rlosmonteiro.imageprocessorservicespi.provider.JPGImageProcessorProvider  
    com.github.c4rlosmonteiro.imageprocessorservicespi.provider.PNGImageProcessorProvider

To see the result of our implementation, we need to finally use the ServiceLoader class to load our providers.

public class ImageProcessorApp {
  private final List<ImageProcessorService> imageProcessorProviders;

  public ImageProcessorApp() {
    final ServiceLoader<ImageProcessorService> imageProcessorServiceLoader = ServiceLoader.load(ImageProcessorService.class);
    final Iterator<ImageProcessorService> imageProcessorServiceIterator = imageProcessorServiceLoader.iterator();

    this.imageProcessorProviders = new ArrayList<>();

    while (imageProcessorServiceIterator.hasNext()) {
      imageProcessorProviders.add(imageProcessorServiceIterator.next());
    }
  }

  public void processImages(final String type) {
    for (final ImageProcessorService imageProcessorProvider : imageProcessorProviders) {
      if (Objects.equals(imageProcessorProvider.getType(), type)) {
        imageProcessorProvider.process();
        return;
      }
    }

    throw new RuntimeException("No provider found to process image type: " + type + ". Create a new provider for it!");
  }
}

Finally, we create a simple main class and execute our code.

public class Main {
  public static void main(final String[] args) {
    final ImageProcessorApp imageProcessorApp = new ImageProcessorApp();
    imageProcessorApp.processImages(BasicImageType.PNG.name());
    imageProcessorApp.processImages(BasicImageType.JPG.name());
    imageProcessorApp.processImages("MY_CUSTOM_OR_NOT_SUPPORTED_IMAGE_TYPE");
  }
}

Run and check the logs.

Processing PNG image
Processing JPG image
Exception in thread "main" java.lang.RuntimeException: No provider found to process image type: MY_CUSTOM_OR_NOT_SUPPORTED_IMAGE_TYPE. Create a new provider for it!
    at com.github.c4rlosmonteiro.imageprocessorservicespi.ImageProcessorApp.processImages(ImageProcessorApp.java:30)
    at com.github.c4rlosmonteiro.imageprocessorservicespi.Main.main(Main.java:8)

Check the source code on github.com.

Before you go!

Follow for more ;)
Suggest new topics
Use the comments section to discuss the feature and >comment on real-world use cases to help others understand >its usage

#javaunderthehood