Add FEST-Assert like syntax about javahamcrest

[npryce]

It sounds like it work well as an add-on library. I'm not sure what the API would look like and how it would support all uses that Hamcrest is put to (e.g. matching parameters of mock objects, defining wait rules for async testing, validation in GUIs, etc.). Why don't you put something together and publish it in a repo so we can see?

[derari]

I was thinking about the fluent topic for a while. A clear benefit of FEST's fluents is better auto-completion, the disadvantage is that it's harder to extend. Reimplementing FEST-Assert makes no sense, if you want that, just use FEST. Hamcrest relies on static factory methods, so I did a little prototype. It relies on the existing factory methods, but reduces the nesting of parentheses and simplifies chaining conditions.

You can find the code here
https://github.com/derari/cthul/blob/master/matchers-fluent/src/test/java/org/cthul/matchers/fluent/ConceptTest.java

The API is not complete yet, but I think this will be the general direction.

[paulduffin]

The purpose of reimplementing FEST on top of Hamcrest is to allow people to
use the style they like while still leveraging available Matcher
implementations. What makes no sense to me is FEST being completely
standalone in the first place. FEST 1 has a Condition class which is
basically a Hamcrest Matcher. FEST 2 appears to rename it to, guess what,
you've got it Matcher!!!

The advantage you and others assert (pun intended) for FEST is at best
transitory as it relies on a limitation in the IDEs which will be addressed
at some point. Intellij IDEA does quite well but could do better.

I like the DSL, very similar to how I was envisaging composition operators
to work in fluent Hamcrest.

Truth looks quite interesting; actually had to upgrade my IDE for it to
handle its use of generics properly.
On 16 Jul 2013 20:53, "Arian" [email protected] wrote:

I was thinking about the fluent topic for a while. A clear benefit of
FEST's fluents is better auto-completion, the disadvantage is that it's
harder to extend. Reimplementing FEST-Assert makes no sense, if you want
that, just use FEST. Hamcrest relies on static factory methods, so I did a
little prototype. It relies on the existing factory methods, but reduces
the nesting of parentheses and simplifies chaining conditions.

You can find the code here

https://github.com/derari/cthul/blob/master/matchers-fluent/src/test/java/org/cthul/matchers/fluent/ConceptTest.java

The API is not complete yet, but I think this will be the general
direction.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-21068746
.

[Derbeth]

This probably is just an off-topic, but for me FEST offers more matchers for common use cases (like matchers for strings against regular expressions, which Hamcrest does not have and, according to #36, does not plan to have), plus their assertions on extracted properties of an iterable/array allow saving lots of repetitive work in an another common use case (again, Hamcrest fails to provide a solution in the standard library).

For me, FEST is much more than syntactic sugar added.

[paulduffin]

I agree that hamcrest should provide more matchers by default. I found some
missing while trying to build FEST like syntax on top. However, I think
that FEST has to provide more because it is less extensible.

I think that Hamcrest should by default provide all Matchers that can be
written on the basic Java libraries, maybe split into similar package
structure. There is no real cost involved for users and developers to do
that. Library providers should provide Matchers for their types.

I have avoided comparing the set of available Matchers in comparisons of
the two because while important it is easily rectified. Also it is not one
sided as Hamcrest has some that FEST does not, or at least allows them to
be composed. I am more interested in the fundamental, i.e. design
differences, that define their usage patterns and more difficult or
impossible to change.
On 17 Jul 2013 06:59, "Piotr Kubowicz" [email protected] wrote:

This probably is just an off-topic, but for me FEST offers more matchers
for common use cases (like matchers for strings against regular
expressions, which Hamcrest does not have and, according to #36#36,
does not plan to have), plus their assertions on extracted properties of
an iterable/arrayhttps://github.com/alexruiz/fest-assert-2.x/wiki/Tips-and-tricks#assertions-on-extracted-properties-of-an-iterablearrayallow saving lots of repetitive work in an another common use case (again,
Hamcrest fails to provide a solution in the standard library).

For me, FEST is much more than syntactic sugar added.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-21093717
.

[derari]

Just for the record: I would not say that what I did is a reimplementation of FEST, because of the architectural differences.

(For those who don't know FEST: FEST has a deep hierarchy of assert classes and a separate assert method for every value type, which makes it difficult to extend, and uses conditions/matchers only as a workaround for extensions. Hamcrest has a shallow hierarchy of matchers and, just like my fluent DSL, provides only a few variants of the same assert method. You cannot do assertThat(3).isLessThan(5) with my approach.)

I agree that the advantage of FEST will disappear as IDEs and the compiler get better at implying generic types, although FEST still has fewer parentheses.

Also, for the DSL I introduced the concept of adapters. It would be quite easy to implement a property adapter that reads a value via reflection.

Paul, I don't know how far you got with your own implementation and how much time you have, but maybe it would make sense to join our efforts?

[npryce]

"Hamcrest ... provides only a few variants of the same assert method"

Remember that Hamcrest is not only used for writing assert statements. It is used in many other contexts.

[derari]

This was no criticism, on the contrary, this difference is the strength of Hamcrest which also reflects in the design of the DSL.

[npryce]

I'm going to close this issue as "will not implement" because:

• It would be a significant change in direction for the API. Hamcrest's style is to use function composition rather than method chaning.
• It can work as an extension library that uses Hamcrest's existing classes and extension points.

When you write it as an extension library, raise an issue with a link to the project so that we can add it to the list of extensions on https://github.com/hamcrest/JavaHamcrest/wiki/Related-Projects