New features :

• github #5 : DateTime and LocalDateTime equals comparison with a precision level

One can now compare DateTime and LocalDateTime ignoring millisecond to hour fields in comparison, see the examples below :

// comparing DateTime ignoring milliseconds.
DateTime dateTime1 = new DateTime(2000, 1, 1, 0, 0, 1, 0, UTC);
DateTime dateTime2 = new DateTime(2000, 1, 1, 0, 0, 1, 456, UTC);
assertThat(dateTime1).isEqualToIgnoringMillis(dateTime2); // OK

// comparing DateTime ignoring hours, minutes, seconds and milliseconds.
DateTime dateTime1 = new DateTime(2000, 1, 1, 23, 59, 59, 999);
DateTime dateTime2 = new DateTime(2000, 1, 1, 00, 00, 00, 000);
assertThat(dateTime1).isEqualToIgnoringHours(dateTime2); // OK

• Guava assertions modules (e.g. Multimap assertions)
• Joda Time assertions modules (e.g. DateTime assertions)

Note that those modules relies on FEST-Assert core 2.0M8.

FEST provides assertions for core types, guava and joda time but it also let you create assertions for your own classes. This is now easy with Fest assertions generator tools.

FEST provides 3 custom assertions generation tools :

• a command line interface tool
• a maven plugin
• an eclipse plugin

Those tools take your specific classes and generate assertions for them by looking at their properties.

Lets’s take an example with a Player class :

package example;
public class Player {
   // getter omitted for brevity
   private String name;
   private int age;
   private boolean rookie;
   private String[] teams;
}

You can generate a PlayerAssert class that will provide assertions for each Player property, and use them like this :

<pre>String[] teams = {"Cleveland", "Miami"};
Player player = new Player("Lebron James", 28, false, teams);
// you can make a static import if you don't want to see PlayerAssert.
PlayerAssert.assertThat(player).hasAge(28).hasName("Lebron James").hasTeams("Miami");

You can have a look at the full PlayerAssert code here.

Many thanks for all the votes!

All of the FEST modules have a separate github project, with its own documentation and issue tracker.

The FEST projects are:

• Swing Testing 1.x
• Assertions 1.x
• Assertions 2.x
• Reflection
• Common Utilities

One of the biggest changes in this release is the implementation of Ansgar’s "Self Types." By using this brilliant technique we ended up with a smaller, cleaner code base that is easier to maintain.

Here are some numbers, comparing this release with the previous one:

Please note that 1.4 has more features than 1.3 and yet the code base is 35% smaller!

Release notes

Bug

• [FEST-378] - Newly added assertThat(Iterable<?> actual) eagerly calls iterator() and can throw an NPE
• [FEST-402] - onProperty is unable to access properties from Object class
• [FEST-414] - Impossible to use Fest Assert 1.3 with Ivy
• [FEST-415] - IteratorAssert should delay Iterator comsumption as much as possible
• [FEST-416] - NPE in MapAssert due to FEST-329

Improvement

• [FEST-105] - Add isEither, or isOneOf
• [FEST-413] - Implement Ansgar's Self Types
• [FEST-423] - User-friendly date and calendar formatting

New Feature

• [FEST-111] - Add support for regular expression matching to StringAssert
• [FEST-381] - collection onProperty() assert might give nicer exceptions
• [FEST-400] - Add generic assertions isIn / isNotIn

You can download the latest release here (file fest-assert-1.4.zip.) FEST-Assert requires Java SE 5.0 or later.

Here are some useful links:

• Home Page
• Documentation (wiki)
• Javadocs
• Issues
• Users' Group

Feedback is always appreciated :)

This past JavaOne was fun for sure. Since there is not too much I can add that hasn’t been covered by the media, I’m just going to talk about the session that Yvonne and I presented.

The title of the session was “Rich GUI Testing Made Easy.” Here is the abstract:

Testing GUIs is essential to making applications safer and more robust. Even the simplest GUI can enclose some complexity. Any complexity needs to be tested: code without tests is a potential source of bugs. A well-tested application has a greater chance of success.

GUI development has been slow to include automated testing as a core practice, because writing tests for GUIs is hard. In this session, we’ll explore several practices that can simplify testing of Swing and JavaFX GUIs.

The session went pretty well. My original thought is that there wouldn’t be too many many people attending, since our session was scheduled in the morning after the big Oracle party. To make things worse, the room we got was so hard to find. At the end, the room was full! and we got pretty good feedback about the presentation :)

You can find our slides here:

Many thanks to Peter Pilgrim for the picture!

After being around for close to 4 years, FEST finally got a pretty cool logo!

The logo was created by Nathan Anderson. Thanks Nathan!

We also replaced our old wiki with WordPress. The main benefits are easier content maintenance and the ability to post news (e.g. new releases) as blog entries with timestamps. Hopefully in the future we can enable blogging accounts for all team members!

Feedback is always appreciated!