Verifying DateTime and Date with Hamcrest

Since I started diving into automated testing and practicing TDD, verification of date values was pain. Luckily there is nice library for legacy Date and new Java 8 DateTime APIs, which cures this pain.

If you belong to healthier part of Java development community and practicing unit testing on daily basis, you probably are aware of Hamcrest Java library. It can make your tests much more readable. It’s architecture is very modular and is used by various other testing libraries.

Major part of it’s flexibility is it concept of Matcher. I am not going to dive into this concept now. If you are not familiar, just take a quick look at Hamcrest tutorial. One of the matcher you can plug into your testing toolbox is library hamcrest-date. With this library we can easily test that date was generated within certain range:

    public void validateDate() {
        Date expectedDate = new Date();

        Date actualDate = new Date();

        assertThat(actualDate, DateMatchers.within(2, ChronoUnit.SECONDS, expectedDate));

We can do that also for Java 8 types:

    public void validateDateTime() {
        LocalDateTime expectedDateTime =;

        LocalDateTime actualDateTime =;

        assertThat(actualDateTime, LocalDateTimeMatchers.within(2, ChronoUnit.SECONDS, expectedDateTime));

Or pick various exotic verifications hamcrest-core library provides:

    public void validateZonedDateTime() {
        ZonedDateTime expectedDateTime = ZonedDateTime.of(2016, 3, 20, 13, 3, 0, 0, ZoneId.of("GMT+1"));

        ZonedDateTime actualDateTime = ZonedDateTime.of(2016, 3, 20, 13, 3, 0, 0, ZoneId.of("GMT-0"));

        assertThat(actualDateTime, ZonedDateTimeMatchers.sameDay(expectedDateTime));
        assertThat(actualDateTime, ZonedDateTimeMatchers.after(expectedDateTime));
        assertThat(actualDateTime, ZonedDateTimeMatchers.isSunday());
        assertThat(actualDateTime, ZonedDateTimeMatchers.isMarch());

Kudos to creator for this nice little library. This example is hosted in Github.

Create UML diagrams with simple DSL – PlantUML

Historically I disliked creating design UML diagrams, because the tooling for it mostly requires drawing boxes and connecting them with lines or arrows. I find such workflow very time consuming and wasteful. This short blog post will describe much better way to create UML diagrams.

But first of all, you may argue that UML importance in today’s agile software development world is fading out. I would agree partially.

Creating UML Class Diagrams

From my point of view UML class diagrams are needed very rarely. I can find only two use cases for it:

  • To analyze existing code base
  • To communicate suggested design with the team

When you need to analyze existing code base, class diagrams can be easily generated by your IDE from the existing code. IntelliJ idea provides this as part of payed version:UML

To find out how to create such diagram, read this IntelliJ IDEA documentation. It is also easy with Eclipse or it’s flavors (e.g. Spring Tool Suite):


You just need to use plugin called ObjectAid.

When we need to sketch class diagram upfront to consult design with the team, I would suggest to create prototype with desired class structure instead and generate class diagram from the live code (again with IDE). You may find some important facts about the design while creating prototype. There’s no need to create logic and tests, just APIs of the design.

And of course when you don’t need such generated diagram anymore, just wipe it out. Low level design may change easily and you don’t want to keep outdated diagrams around. You can generate new diagram from live code easily.

Non-Class diagrams

So when we need Class diagram, it’s smart to generate it from live code. But what about other UML diagrams like:

  • Structure diagrams (except Class diagram)
  • Behavioral diagrams
  • Interaction diagrams (especially useful is Sequence diagram from this bucket)

I personally created only few Use case and Flow chart diagrams during my career. But Sequence and Component diagrams are very useful to document high-level design decisions. Of course you don’t want to have them very detailed, but at high level designer intentions and considerations are sometimes good to document.

But the tool that is used for designing these diagrams has to be very easy to use and flexible. Sorry Visio or Enterprise Architect, I don’t include you into this bucket (although I have to admin I haven’t use EA for long time).

My tool of choice it PlantUML. We can define design with very simple DSL. Therefore instead of connecting boxes and lines on canvas, we can focus on design itself. It can be used as standalone application but it also have impressive list of integrations. So you can easily use it with your IntelliJ IDEA, Eclipse or Spring Tool Suite.

Very compelling fact for me, is that DSL which defines diagrams can live with the project code-base and also be handled by source control system, with all the goodness it brings. This is simple screenshot from IntelliJ: