keeganwitt / gmock

Automatically exported from code.google.com/p/gmock
6 stars 2 forks source link

Closure matcher #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Support for closure matcher:

mock.put(match{ it > 1 }, match{ it in 3..5 }) // closure matchers

Original issue reported on code.google.com by julien.g...@gmail.com on 12 Oct 2008 at 9:50

GoogleCodeExporter commented 9 years ago

Original comment by JohnnyJianHY on 12 Oct 2008 at 12:21

GoogleCodeExporter commented 9 years ago
Closure matchers can be implemented by hamcrest matcher, that is, something 
like:
    match{ it == 1 }
can return a instance of org.hamcrest.Matcher, then we can just handle 
org.hamcrest.Matcher. So, I think we should implement both closure matchers and 
hamcrest matchers in same version.

Original comment by JohnnyJianHY on 13 Oct 2008 at 1:27

GoogleCodeExporter commented 9 years ago
Yes you are probably right. However I wasn't expecting that we add a dependency 
on
Hamcrest. Gmock is all about simplicity and asking people to download another 
jar
when they've done the effort of downloading ours is sometimes to much.

So we should define exactly the set of hamcrest style matcher we want and make 
sure
they are consistent with the rest of the API.

I probably had that in mind when I separated both issue, thinking we could have 
the
closure matcher as a first step.

Original comment by julien.g...@gmail.com on 13 Oct 2008 at 7:02

GoogleCodeExporter commented 9 years ago
In the future, we will have to update junit to version 4.5 which already 
depends on 
hamcrest, so users have to download hamcrest even if gmock doesn't depend on it.
I regard defining a set of matchers as reinventing the wheel. What's more, if 
someone has experience on hamcrest matchers, then he can reuse all these 
expreiences 
if we support hamcrest matchers.

Original comment by JohnnyJianHY on 13 Oct 2008 at 9:26

GoogleCodeExporter commented 9 years ago
I think you are probably right. We should come with a way where including this 
third
party library be an option - that would be my preference. And yes we should
definitely not reinvent the wheel.

Original comment by julien.g...@gmail.com on 13 Oct 2008 at 5:38

GoogleCodeExporter commented 9 years ago
So, what's your point? Do you mean that "match{ it == 1 }" should return an 
instance 
of an internal matcher of gmock, instead of org.hamcrest.Matcher, then it can 
be 
independent with hamcrest matchers if users only use closure matchers, right?

Original comment by JohnnyJianHY on 14 Oct 2008 at 1:41

GoogleCodeExporter commented 9 years ago
Yes you right, match should be hamcrest independent. Shouldn't be complicated.

Original comment by julien.g...@gmail.com on 14 Oct 2008 at 6:46

GoogleCodeExporter commented 9 years ago
It is very easy to support hamcrest matchers, should we support it in 0.4?

Original comment by JohnnyJianHY on 17 Oct 2008 at 9:42

GoogleCodeExporter commented 9 years ago
Yes. I can see why not. Issue-20

Original comment by julien.g...@gmail.com on 17 Oct 2008 at 3:26

GoogleCodeExporter commented 9 years ago

Original comment by JohnnyJianHY on 19 Nov 2008 at 6:17

GoogleCodeExporter commented 9 years ago

Original comment by JohnnyJianHY on 19 Nov 2008 at 8:04