Comments (6)
I've added a test for this, but it works in my environment. Can you tell us
more about your platform/runtime?
I'll close it for now until we can reproduce the failure.
Original comment by [email protected]
on 18 Oct 2008 at 8:06
- Changed state: Invalid
- Added labels: Priority-High
- Removed labels: Priority-Medium
from hamcrest.
The test might well work if it's in the same package as the getter, as the test
then
has permissions that a test in another package does not. Is your test in the
same
package?
I've certainly had this problem in our environment (plain old JRE v5) and in
fact
have had to write our own alternative Matcher to get round the problem. The
fix is
basically to put in a setAccessible(true) call on the getter method, and to
ensure
that the test class is not in the same package.
Original comment by [email protected]
on 18 Oct 2008 at 2:55
from hamcrest.
If the getter is not accessible, then it's not a Bean property accessor, as
defined
by Java Beans.
The matcher should not throw IllegalAccessException. It should return false in
this
situation.
Original comment by [email protected]
on 18 Oct 2008 at 3:43
from hamcrest.
I hope it's not really about JavaBeans, and it still can fail even if the
getter is
public.
The standard situation is that you have an interface (as in the original
example)
exposing a getter, or maybe a getter and a setter. Then you have a class which
implements that interface via a public getter and public setter method. But you
make
that class package protected because you're exposing it through a factory method
which has a return type of the interface.
All completely standard stuff. Now you want to test it. hasProperty is the
obvious
candidate, but because the implementation class is not public, hasProperty
doesn't work.
A public getter method exposed via a public interface really ought to be
directly
testable via hasProperty: I've had several people come to me at work and
complain
that they "don't like Hamcrest because hasProperty doesn't work properly".
(That is,
it doesn't work as they expect.)
If you want to make this return false instead of throwing an exception on a
getter
that isn't publicly visible on a public class, insisting on sticking with the
JavaBeans line, fair enough. But it does surprise people. And so then an
alternative matcher that does provide access in this very standard case (public
interface, either public or non-public implementation) is very definitely
needed. As
I said, we had to write one as people are always wanting to make assertions
about
things accessed via interfaces, and it's basically exactly hasProperty but with
a
setAccessible(true) in the middle. :-(
Why use hasProperty or a matcher at all?
Well, the error messages coming out of
assertThat(foo, hasProperty("bar", equalTo(5)));
are much clearer than:
assertThat(foo.getBar(), equalTo(5));
even though it's more typing and you don't get refactoring or compiler support.
Original comment by [email protected]
on 18 Oct 2008 at 4:13
from hamcrest.
[deleted comment]
from hamcrest.
If you write a method called "getXXX" that doesn't automatically make it a
getter for
a property called "xxx". You happen to have a name that follows a convention
defined
by part of the Java Beans spec. Unless you follow the rest of the spec, it's
not a property. It's just a method with a name that starts with "get".
Original comment by [email protected]
on 19 Oct 2008 at 1:16
from hamcrest.
Related Issues (20)
- PatternMatcher HOT 5
- hasItem is not working HOT 6
- Patch for /trunk/hamcrest-objectivec/CHANGES.txt
- Link to "current" doc HOT 4
- Make SamePropertyValuesAs extendable HOT 1
- Use of expressions to check "hasProperty" in beans HOT 2
- Errors from String.valueOf() in BaseDescription makes some Exceptions un-reportable. HOT 1
- BigDecimalCloseTo bug in error message HOT 1
- containsString helper should cast value to string
- Hamcrest 1.3 CoreMatchers.hasItem(...Matcher)
- maven install hamcrest error
- proposal for new JavaGenerator replacing the XML configuration file HOT 3
- Matchers.arrayContaining(Matcher...) does not work with primitive arrays
- Espresso dependency specifically for the app under test HOT 1
- equalTo calls actual.equals(expected) instead of expected.equals(actual)
- License file collision with android.
- Matchers.contains does not always work for lists HOT 1
- Failing test cases testReadsGenerifiedParameterTypes
- array mismatch description should not just use array element toString value in mismatch description
- Show a readable diff as part of the failure description for assertThat
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hamcrest.