Tu I Jo Asseguts A La Barra D’un Bar, Sona Bona Música I Som Davant Del Mar (Al Mar - Manel)

In current post I am going to talk about differences between Hamcrest and Fest Fluent Assertions. The reason of this post is not to tell you if you should use one or the other. I only want to show you how both implementations resolve the problem of writing readable assertions.

To compare both APIs I have created two JUnits, one using Hamcrest assertions and one where Fest assertions are used.

The comparision is done using only common operations (Logical, Object, Collections, Number, Text) and creation of new matchers. I am not going to compare which ones have implemented more matchers or kinds of matchers, because I think this is not a parameter to use for choosing what library fits better to your project. Moreover in both APIs you can extend them for creating your own matchers.

Let's start showing model representing a simple modelling of Studio Ghibli http://en.wikipedia.org/wiki/Studio_Ghibli movies information. 

Imports:

Hamcrest requires 11 imports:

while Fest requires 2 imports:

in fact this is not a good or bad thing how many imports are required, but it is always a headache remember where a required assertion is packaged. Because Fest uses Fluent Interfaces approach with two imports all operations are available with IDE's "auto-completation" feature.

Simple asserts:

Not much difference between Hamcrest and Fest, in case of Fest verb is also added in method name creating a much readable assert.

Hamcrest

Fest

Logical asserts:

In this case we find a big difference. Hamcrest supports logical operations and can be used independently, meanwhile logical operations in Fest are a part of the method:

Hamcrest

Fest

Object asserts:

Same object operations are provided in both APIs. There is only one difference, in Fest you can chain callings of methods, so number of asserts compared to Hamcrest are fewer.

Hamcrest

Fest

Collection asserts:

In case of Collections is where they differ more from each other. Hamcrest deals with Collections and Maps with methods like hasKey, hasValue, hasItem. Fest uses a more generic calling like includes, excludes, entry; I have not found any way for asserting key instead of key-value in Fest.
Moreover in this example I also compare how to access a bean property in each elements of collection. From my point of view I think that Fest has a better approach resolving this case.

Hamcrest

Fest

Number asserts:

As in simple asserts, there is no much difference between them.

Hamcrest

Fest

String asserts:


Hamcrest

Fest

As you have noted Hamcrest and Fest are very similar, but I think that Fest solves the same problem but in much cleaner way.

Although both solutions offer very similar matchers, each implementation is so different, so creation of a custom matcher is different too. In Hamcrest you should create a class that extends from TypeSafeMatcher. In Fest there are two possibilities, first one is extending Fest-assertions with custom condition (using already Fest structure and defined types), and the second one is extending with custom assertion (creating a new assertThat implementation for required type).

Hamcrest extension for asserting that a character is a human:

In case of Fest there are two approaches, the first one, that requires that our class extends from Condition. As I told previously, extending Condition implies using the same kind of types supported by org.fest.assertions.Assertions.assertThat method (object, int, short, list, array, ...). In previous case our type is Character, and of course does not exist an overload of Assertions.assertThat method with Character, but java.lang.Object. So our class should be:

As you probably noted, you need to cast character variable to Character, neither a clean solution nor optimal. But of course you can use second method, extending from GenericAssert. This class (a Fluent class) will be the responsible of implementing an assertThat that accepts Character objects, and moreover will implement matcher methods. And I say methods because unlike Hamcrest, Fest can contain more than one matcher in each class. For example if there are some tests that we are asserting if character is human, and in another ones asserting if is human and if has a name, in Hamcrest we should create two classes. In Fest you don't have this restriction.

As it is told in Fest site "Which one to use? Hamcrest or FEST-Assert? It is up to you...it depends on the needs of your project and your coding style!"

Download code.

Music: http://www.youtube.com/watch?v=GjWLXZ4WdQU

Umetxoak Ikusirik Lorea Ezin Bizirik Arantzak Kendu Nahi Dizkio Bizi Berri Bat Eman (Loretxoa - Benito Lertxundi)

EJP (or Easy Java Persistence) is a powerful and easy to use relational database persistence API for Java. It has no need for mapping Annotations or XML configuration, and there is no need to extend any classes or implement any interfaces. In it is site we can find the following statement: "EJP is, by far, the easiest persistence API available for Java."

From my point of view EJP is a mixture of some features between myBatis and Spring Jdbc Template Row Mapper.

An example of EJP from its website:

and Customer and Support classes are simple POJOs without annotations or any special tag, and no configuration file.

What I am going to explain in this post is how integrate EJP with Spring.

First of all, we are going to create an interface which defines all permitted operations:

This is an example of common operations provided by EJP. Methods that should be clarified are:

• newDatabase method is used for returning a Database object. This object is a facade that implements all operations supported by EJP. It is the main class of EJP project with permission of DatabaseManager class.
• loadAssociations are responsible (as its name suggests) to load an object associations.
• queryForObject methods execute a "query by example" queries.
• queryForInt is a method used for queries that return numerical results like count(*), avg(...), ...

EjpJdbcTemplate is the implementation of previous interface, and makes use of JdbcTemplate class as core.

Getting a new Database:

Remember that Database object is the core of EJP, and is required to execute all EJP operations. This method creates one Database with given Connection. databaseName is not mandatory, but for no reason is a constructor attribute. A null can be passed without any problem. In this implementation database name is a class attribute.

Deleting:

No secret in deleting an object. Using ConnectionCallback, connection is provided, and Database object is created.

Loading Associations:

If you want to load explicitly all associations of an object, load associations method must be called. The only integration difficult is that database.loadAssociations returns void, and ConnectionCallback should always return a result. In this case void.TYPE is used.

Executing Queries:

In this case most important line is where Database executeQuery method is called. This method returns a class of type Result. This class is a wrapper of ResultSet class but also can deal directly with beans (implicit wrapping), instead of getting one-by-one each parameter. But for following JdbcTemplate strategy and use a row mapper, ResultSet is used for mapping results.

Querying for Int:

See that follows the same schema as executeQuery, but instead of using RowMapperResultSetExtractor, a SingleColumnRowMapper is used. This mapper is used when the query result returns a single result.

Now I am going to show how to use this template into a DAO implementation.

Not much secret in this DAO. Only two methods requires special review findAllCustomersOrderedByName() and findCustomerByExample()

The first one:

this.template.queryForObject(Customer.class, "ORDER BY first_name",BeanPropertyRowMapper.newInstance(Customer.class)) 

 is converted by EJP to SELECT * FROM Customer ORDER BY first_name.

The second one:

this.template.queryForObject(customer, BeanPropertyRowMapper.newInstance(Customer.class)) 

instead of receiving a Class it receives an instance itself to execute the query. In case that first name field was set to alex, the equivalent SQL query would be SELECT * FROM Customer WHERE first_name='alex'

Now I have explained a strategy to integrate EJP with Spring. Because I have followed same structure as Spring-Data Jdbc-Extension project, rather than create a "HelloWorld" project, I decided to fork Spring-Data project into my Github account, and uploaded the code as a new extension for the project. Moreover a Jira issued has been created with id DATAJDBC-11. If you want to watch full code and unit tests go to git@github.com:maggandalf/spring-data-jdbc-ext.git and review spring-data-jdbc-ext/spring-data-jdbc-core/src/main/java/org/springframework/data/jdbc/ejp directory.

I wish you have found this post useful.


Music: http://www.youtube.com/watch?v=PlEknDUSRc0&feature=fvwrel