Closed GoogleCodeExporter closed 8 years ago
Hi,
Is this a known issue. Do i need to include any other jar ?
Original comment by akhilbha...@gmail.com
on 25 Jan 2012 at 5:56
Hi
I don't think this is an issue with Mockito as it is the compiler that
complains. You should probably try to make sure the "isValid()" method can
actually be found by the compiler, either by looking at classpath, the imports,
the visibility or if isValid has a generic return type make sure that the
return type is explicitly written.
Also windows XP doesn't really interest us, however which JVM is a much more
interesting information ;)
Hope that helps.
Original comment by brice.du...@gmail.com
on 29 Jan 2012 at 5:58
Hi,
I am using "mockito-all-1.9.0.jar".
I Don't think, its a class path issue because, i am using Eclipse IDE and i
have included it in the build path & moreover, other methods like when, anyInt
etc are working.
I Suspect my imports but not sure, can you check this once. I have done the
below imports:
import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
& i mentioned windows XP due to the format of the Question submission given
here :). i am using java6.
please let me know, if i need to provide some more details.
Original comment by akhilbha...@gmail.com
on 30 Jan 2012 at 4:28
Hi,
Mockito doesn't have an "isValid()" method.
anyInt() doesn't expect any arguments, so basically with your imports it should
work. While the method
"org.mockito.Matchers.argThat(org.hamcrest.Matcher)" actually takes an Hamcrest
matcher, so a method "isValid()" in your code should exists and return an
Hamcrest Matcher.
Please note that at the moment Mockito only supports Hamcrest 1.1, not the
upper versions.
Original comment by brice.du...@gmail.com
on 30 Jan 2012 at 9:14
Original comment by brice.du...@gmail.com
on 1 Feb 2012 at 1:10
I use rest-assured library which uses hamcrest 1.2, so I had to go with version
1.2. Please add support for 1.2
Original comment by ar...@identified.com
on 25 Feb 2012 at 5:04
The problem is that we should stay compatible with hamcrest 1.1. Or even move
away the hamcrest dependency.
Original comment by brice.du...@gmail.com
on 29 Feb 2012 at 12:46
hamcrest is a great library, why do you want to move away from it? :)
Original comment by ar...@identified.com
on 29 Feb 2012 at 5:27
Yeah hamcrest is pretty good. But this means we have to spend time on
maintaining this dependency. But I mean't is just to have an hamcrest
integration module. Anyway this movement hasn't yet started.
But today, I don't feel the need for Hamcrest anymore. Here's why, usually we
either need the simple mathcer or more complex matching.
For complex matching now I'd rather use an ArgumentCaptor in combination with
FESTAssert, which is cleanier that using hamcrest.
Also I don't think this is the right issue to discuss this matter, issue 297 is
much more relevant.
Original comment by brice.du...@gmail.com
on 29 Feb 2012 at 5:38
>hamcrest is a great library, why do you want to move away from it? :)
We want to support it in some way so that for example users can take advantage
of their own custom matchers with mockito. However, we don't want to use
hamcrest internally because it's a liability. The hamcrest api changes or might
change and it impacts the end user of Mockito. That's it :)
Original comment by szcze...@gmail.com
on 11 Mar 2012 at 11:29
Original issue reported on code.google.com by
akhilbha...@gmail.com
on 25 Jan 2012 at 5:45