DEV Community: armandino

Is there any reason to use ZoneId.of("UTC") instead of ZoneOffset.UTC?

armandino — Fri, 24 Jun 2022 17:48:14 +0000

I came across this question on StackOverflow:

Is there any reason to use ZoneId.of("UTC") instead of ZoneOffset.UTC?

Since I had to deal with an issue related to this question in production, I wanted to share my answer here because I think it might be useful to anyone serializing ZonedDateTime with Jackson.

Tl;dr if you use Jackson, you might be better of using ZoneId instead of ZoneOffset.

I can think of one situation where ZoneId.of("UTC") might be preferable over ZoneOffset.UTC. If you use jackson-datatype-jsr310 to deserialize ZonedDataTime from JSON, you get dates with ZoneId.

For example, let's say we have this POJO (getters/setters omitted for brevity):

class Example {
    private ZonedDateTime date = ZonedDateTime.now(ZoneOffset.UTC).truncatedTo(ChronoUnit.DAYS);
}

If you print an instance of the class you get:

Example example1 = new Example();
System.out.println(example1);

// output:
// Example(date=2022-06-17T00:00Z) - as expected

What happens when you deserialize JSON containing the above string 2022-06-17T00:00Z?

String json = "{\"date\":\"2022-06-17T00:00Z\"}";
Example example2 = mapper.readValue(json, Example.class);
System.out.println(example2);
// output:
// Example(date=2022-06-17T00:00Z[UTC]) // now with ZoneId(!)

So now we have two variants, one with ZoneOffset and one with ZoneId:

2022-06-17T00:00Z
2022-06-17T00:00Z[UTC]

And these are not equal to each other. For example:

Instant instant = Instant.now();
ZonedDateTime z1 = ZonedDateTime.ofInstant(instant, ZoneOffset.UTC);
ZonedDateTime z2 = ZonedDateTime.ofInstant(instant, ZoneId.of("UTC"));

System.out.println(z1.equals(z2)); // => false

As a result example1.equals(example2) will also be false. This could be a source of subtle bugs.

Note: you get same result if your serialize new Example() to a JSON string and deseralize the string back to an object. You will get a date with ZoneId.

Tested with Jackson 2.13.1.

Instancio: Data Generator For Unit Tests

armandino — Wed, 15 Jun 2022 21:29:01 +0000

This post is about reducing manual data setup in unit tests. Typically such setup involves instantiating some classes and calling a bunch of setters. For example, in the the following test this is done in the createBookDTO() method:

Note: links to source code provided at the end.

// Class under test
private final BookMapper bookMapper = new BookMapper();

@Test
void map() {
    // Given
    BookDTO bookDto = createBookDTO();

    // When
    Book book = bookMapper.toEntity(bookDto);

    // Then
assertThat(book.getTitle()).isEqualTo(bookDto.getBookTitle());
    // ... snip ... remaining assertions
}

// Data setup
private BookDTO createBookDTO() {
     AuthorDTO authorDto = new AuthorDTO();
     authorDto.setAuthorId(UUID.randomUUID().toString());
     authorDto.setFirstName("Jane");
     authorDto.setLastName("Doe");

     BookDTO bookDto = new BookDTO();
     bookDto.setBookId(UUID.randomUUID().toString());
     bookDto.setIsbn("test-isbn");
     bookDto.setBookTitle("test-title");
     bookDto.setAuthor(authorDto);
     bookDto.setGenre(Genre.FICTION);
     bookDto.setPublishedOn(LocalDate.of(1865, 3, 17));
     bookDto.setNumberOfPages(123);
     bookDto.setPriceCents(3099);
     return bookDto;
}

The setup done in createBookDTO() is very typical for unit tests. However, it can be quite tedious, especially when dealing with large classes. What's more is that often the values themselves don't actually matter. Whether you set the name to "Jane Doe" or "Foo Bar" makes no difference. The end result is the same.

If values don't matter, then why not use a library to create and populate an object with random data? This is exactly what Instancio does. It is a library that generates objects for unit tests. Using Instancio, we can create a BookDTO instance as follows:

private BookDTO createBookDTO() {
    return Instancio.create(BookDTO.class);
}

This seems like a step in the right direction, but what if we need to customise some values of BookDTO? Let's say the BookMapper class that we are testing converts string UUID values to UUID type:

UUID.fromString(bookId) // need a valid UUID string!

In this case, the test will fail unless our test objects contain valid ids (notice that setAuthorId() and setBookId() in the original createBookDTO() method are both set to UUID.randomUUID().toString()). To achieve this, we can use Instancio's builder API to set custom values:

Instancio.of(BookDTO.class)
    .set(field(BookDTO.class, "bookId"), UUID.randomUUID().toString())
    .set(field(AuthorDTO.class, "authorId"), UUID.randomUUID().toString())
    .create();

For this simple test the above change is sufficient and now our test will pass. However, Instancio supports a number of other features for customising generated objects, for example:

Instancio.of(BookDTO.class)
    .generate(field("genre"), gen -> gen.oneOf(Genre.CRIME, Genre.SCIFI, Genre.FANTASY))
    .generate(field("isbn"), gen -> gen.text().pattern("#d-#d#d#d#d#d-#d#d#d-#d"))
    .generate(field("numberOfPages"), gen -> gen.ints().range(100, 999))
    .create();

There might be a follow up article to go into more detail. Please leave a comment if you'd like to see more examples, or if you have any questions. All feedback is welcome!

If you are interested in learning more, please see the user guide which also has a number of examples.

You can find the book-mapper-sample project at https://github.com/instancio/instancio-samples

DEV Community: armandino

Is there any reason to use ZoneId.of("UTC") instead of ZoneOffset.UTC?

Instancio: Data Generator For Unit Tests

Links