Add method 'satisfiesforSome' to CollectionAssert, ListAssert and all implementations of ArrayAssert

I got the same idea but not open a issue because, I reflected on the syntax.
Indeed it could be possible to be very accurate :

• areAtLeast(condition, times)
• areAtMost(condition, times)
• areExactly(condition, times)

+ have and negative

A "I don't care" is same as areAtLeast 0 so doesn't need method.

I am working on it, very similar with FEST-468

Cool

I would love to see some examples to see how fluent it is, do you have some already ?

Since you are working on both FEST-371 and FEST-470, as you did for FEST-468, create a git branch for each issue, it will be easier to integrate.

Thanks !

I write

List<String> peoples = list("Yoda", "Luke", "Leia");
assertThat(peoples).areAtLeast(jedi, 2);
assertThat(peoples).doHaveNotAtMost(jediPower, 1);
assertThat(peoples).areNotExactly(jedi, 1);
assertThat(peoples).haveExactly(jediPower, 2);

Error message lile that :

"expecting: elements <['Yoda', 'Solo', 'Leia']> to be at least 2 times <Is a Jedi>"

What do you think of inverting condition and the expected number ?

List<String> peoples = list("Yoda", "Luke", "Leia");
assertThat(peoples).areAtLeast(2, jedi);
assertThat(peoples).doHaveNotAtMost(1, jediPower);
assertThat(peoples).areNotExactly(1, jedi);
assertThat(peoples).haveExactly(2, jediPower);

and for the error message:

"expecting: elements <['Yoda', 'Solo', 'Leia']> to be at least 2 <Jedi>"

I'm not sure we will find a good error message for all the cases because it depends on the Condition description, so I suggest we don't worry to much on that and we pick the formulation that is nice for the majority of the use cases.

Yes good point.
When I got the idea, I thought 'elements are Jedi at least 2 times', but saying aloud 'elements are at least 2 jedis', I think it's more readable and more close to error message.