Assert : Filter API proposal
Joel Costigliola
We need your ideas about the filter we are building for Fest Assert
2.0.
The basic principle is to restrain a collection elements to the ones
you want to make assertions on.
--------------------
Let's start with an example pertaining to basket ball game (which I
enjoy very much when I don't have sprain ankle like right now).
So we have a Team with Player, each Player has a name and some
statistics (point per game, rebounds, assists), we could write things
like :
- assertThat(players).withFilter("team", EQ, "lakers").contains(kobe,
pau);
- assertThat(players).withFilter("team", "lakers").contains(kobe,
pau); // assume that EQ is the default operator
- assertThat(players).withFilter("assists", GT, 5).contains(rondo,
nash, rose)
You have noticed that it uses reflexion to get property values to
compare to expected value with some predefined operator.
Possible operators : equal / notEqual / in / notIn /
greater(OrEqual)Than / less(OrEqual)Than
Here some of the things that cross my mind, it's a draft, we need more
ideas !
A - assertThat(players).withFilter("assists", GT, 5).contains(rondo,
nash, rose)
B - assertThat(players).filteredOn("assists", GT, 5).contains(rondo,
nash, rose)
C - assertThat(players).filteredOnProperty("assists", GT,
5).contains(rondo, nash, rose)
--------------------
We should also offer a fluent builder to create Filter conditions with
OR/AND conjunction, and use it in assertions
AND example :
Filter possibleMVPs = filter(players).with("pointsPerGame", GT,
20).and("assists", GT, 7)
assertThat(players).withFiler(possibleMVPs).containsOnly(james, rose)
OR example :
pointGuardOrCenterFilter = filter(players).with(anyOf("pointsPerGame",
GT, 20).or("rebounds", GE, 10))
AND/OR combined filter (trickier to express) :
goodPointGuardOrRebounderFilter = anyOf(filterOnProperty("assists",
GT, 10), filterOnProperty("rebounds", GE, 10))
Filter possibleMVPs = filter(players).with("pointsPerGame", GT,
20).and(anyOf(filterOnProperty("assists", GT, 10),
filterOnProperty("rebounds", GE, 10)))
Filter possibleMVPs = filter(players).with("pointsPerGame", GT,
20).and(goodPointGuardOrRebounderFilter)
We could also write using natural operator precedence : A || B && C <-
> A || (B && C)
Filter goodRebounderOrPossibleMVPs = filter(players).with("rebounds",
GE, 10).or("pointsPerGame", GT, 20).and("assists", GT, 7)
We could also make the fluent Filter builder look like a query
language, so instead of :
1 - Filter possibleMVPs = filter(players).with("pointsPerGame", GT,
20).and("assists", GT, 7)
We could do :
2 - Filter possibleMVPs = from(players).where("pointsPerGame", GT,
20).and("assists", GT, 7)
I must say I prefer the first starting with 'filter'.
--------------------
The points that I think to be important :
- easy to read filters
- prefer a simple API to express basic filters that matches 80% of
user needs than a powerful but (too) complex API
All comments and ideas are welcome !
Cheers,
Joel
ps : I haven't programmed any of those suggestions yet, thus some are
maybe impossible to write in Java.
Ansgar Konermann
to me, filtering collections seems to be a separate concern, which
should not be mixed with assertions.
I suggest to factor out filtering and create a new subproject dedicated
to collection filtering, which could be called FEST-Filter.
Besides, I like the "Filter conditions builder" idea, and I'd love to
see a unified approach for expressing conditions in both FEST-Assert and
a potential new FEST-Filter module (i. e. use a consistent API for
FEST-Assert and FEST-Filter conditions).
Looks like we need to invest in inventing a good fluent "Condition
building API"
Best regards
Ansgar
>> A || (B&& C)
Alex Ruiz
I agree with Ansgar. Filtering needs to be separate from the assertion
fluent interface. It can still be in the same project though, but not
in the same method chain.
I made a similar point at http://jira.codehaus.org/browse/FEST-404 ,
here is what I wrote:
<quote>
Before we start working on this feature, I'd like to start a
conversation on the mailing list.
This issue is kind-of-related to an old one that someone brought
sometime ago, suggesting an API for checking exceptions similar to
this:
assertThat(exception).cause().isInstanceOf(IllegalArgumentException.class);
The problem here is the context switch. isInstanceOf does not apply
any more to the original target of assertThat, but its cause. IMO, the
target should never change, which means that every single assertion
method in the chain should apply to the object in assertThat.
I noticed this context-switch too late for onProperty. Please, don't
get me wrong, I love onProperty. But again, it switches targets. In
the 2.x branch, I changed this, in a way that the code needs to be
written as follows:
// employees is a List of Employee
List<?> ids = extractProperty("id").from(employees);
assertThat(ids).contains(32342, 12319);
I suggest to do the filtering in the same way, outside of the
"assertThat" chain.
</quote>
Having said that, I'd love to see the filter API take Conditions to
perform the filtering.
Talking about Conditions, in the 2.x prototype I move all the "heavy
lifting" from the assertion classes to helper, singleton utilities
that can be reused when writing Conditions.
I'll adding the team to the 2.x repo this weekend. I haven't done it
earlier due to time constraints :D
Cheers!
-Alex
> --
> You received this message because you are subscribed to the Google Groups
> "easytesting-dev" group.
> To post to this group, send email to easytes...@googlegroups.com.
> To unsubscribe from this group, send email to
> easytesting-d...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/easytesting-dev?hl=en.
>
>