public class PropertyUtilsTestCase extends TestCase (Code)
Test Case for the PropertyUtils class. The majority of these tests use
instances of the TestBean class, so be sure to update the tests if you
change the characteristics of that class.
So far, this test case has tests for the following methods of the
PropertyUtils class:
getIndexedProperty(Object,String)
getIndexedProperty(Object,String,int)
getMappedProperty(Object,String)
getMappedProperty(Object,String,String
getNestedProperty(Object,String)
getPropertyDescriptor(Object,String)
getPropertyDescriptors(Object)
getPropertyType(Object,String)
getSimpleProperty(Object,String)
setIndexedProperty(Object,String,Object)
setIndexedProperty(Object,String,String,Object)
setMappedProperty(Object,String,Object)
setMappedProperty(Object,String,String,Object)
setNestedProperty(Object,String,Object)
setSimpleProperty(Object,String,Object)
author: Craig R. McClanahan author: Jan Sorensen version: $Revision: 555184 $ $Date: 2007-07-11 07:25:35 +0100 (Wed, 11 Jul 2007) $
testGetReadMethodBasic() Test getting accessible property reader methods for a specified
list of properties of our standard test bean.
public void
testGetReadMethodPackageSubclass() Test getting accessible property reader methods for a specified
list of properties of a package private subclass of our standard
test bean.
public void
testGetReadMethodPublicInterface() Test getting accessible property reader methods for a specified
list of properties that are declared either directly or via
implemented interfaces.
public void
testGetReadMethodPublicSubclass() Test getting accessible property reader methods for a specified
list of properties of a public subclass of our standard test bean.
testGetWriteMethodBasic() Test getting accessible property writer methods for a specified
list of properties of our standard test bean.
public void
testGetWriteMethodPackageSubclass() Test getting accessible property writer methods for a specified
list of properties of a package private subclass of our standard
test bean.
public void
testGetWriteMethodPublicSubclass() Test getting accessible property writer methods for a specified
list of properties of a public subclass of our standard test bean.
testMapExtensionCustom() This tests to see that it is possible to subclass PropertyUtilsBean
and change the behaviour of setNestedProperty/getNestedProperty when
dealing with objects that implement Map.
public void
testMapExtensionDefault() This tests to see that classes that implement Map always have their
custom properties ignored.
Note that this behaviour has changed several times over past releases
of beanutils, breaking backwards compatibility each time.
testNestedPropertyKeyOrIndexOnBeanImplementingMap() There is an issue in setNestedProperty/getNestedProperty when the
target bean is a map and the name string requests mapped or indexed
operations on a field.
The set of property names we expect to have returned when calling
getPropertyDescriptors(). You should update this list
when new properties are added to TestBean.
public void testExceptionFromInvoke() throws Exception(Code)
Test
PropertyUtilsBean 's invoke method throwing an IllegalArgumentException
and check that the "cause" has been properly initialized for JDK 1.4+
See BEANUTILS-266 for changes and reason for test
Base for testGetDescriptorXxxxx() series of tests.
Parameters: name - Name of the property to be retrieved Parameters: read - Expected name of the read method (or null) Parameters: write - Expected name of the write method (or null)
Positive getPropertyDescriptor on property intProperty.
testGetDescriptorInvalidBoolean
public void testGetDescriptorInvalidBoolean() throws Exception(Code)
Negative tests on an invalid property with two different boolean
getters (which is fine, according to the JavaBeans spec) but a
String setter instead of a boolean setter.
Although one could logically argue that this combination of method
signatures should not identify a property at all, there is a sentence
in Section 8.3.1 making it clear that the behavior tested for here
is correct: "If we find only one of these methods, then we regard
it as defining either a read-only or write-only property called
<property-name>.
Base for testGetReadMethod() series of tests.
Parameters: bean - Bean for which to retrieve read methods. Parameters: properties - Property names to search for Parameters: className - Class name where this method should be defined
Base for testGetWriteMethod() series of tests.
Parameters: bean - Bean for which to retrieve write methods. Parameters: properties - Property names to search for Parameters: className - Class name where this method should be defined
This tests to see that it is possible to subclass PropertyUtilsBean
and change the behaviour of setNestedProperty/getNestedProperty when
dealing with objects that implement Map.
testMapExtensionDefault
public void testMapExtensionDefault() throws Exception(Code)
This tests to see that classes that implement Map always have their
custom properties ignored.
Note that this behaviour has changed several times over past releases
of beanutils, breaking backwards compatibility each time. Here's hoping
that the current 1.7.1 release is the last time this behaviour changes!
Test the mappedPropertyType of MappedPropertyDescriptor.
testNestedPropertyKeyOrIndexOnBeanImplementingMap
public void testNestedPropertyKeyOrIndexOnBeanImplementingMap() throws Exception(Code)
There is an issue in setNestedProperty/getNestedProperty when the
target bean is a map and the name string requests mapped or indexed
operations on a field. These are not supported for fields of a Map,
but it's an easy mistake to make and this test case ensures that an
appropriate exception is thrown when a user does this.
The problem is with passing strings of form "a(b)" or "a[3]" to
setNestedProperty or getNestedProperty when the target bean they
are applied to implements Map. These strings are actually requesting
"the result of calling mapped method a on the target object with
a parameter of b" or "the result of calling indexed method a on the
target object with a parameter of 3". And these requests are not valid
when the target is a Map as a Map only supports calling get(fieldName)
or put(fieldName), neither of which can be further indexed with a
string or an integer.
However it is likely that some users will assume that "a[3]" when applied
to a map will be equivalent to (map.get("a"))[3] with the appropriate
typecasting, or for "a(b)" to be equivalent to map.get("a").get("b").
Here we verify that an exception is thrown if the user makes this
mistake.