[
https://issues.apache.org/jira/browse/SANDBOX-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198694#comment-13198694
]
Benedikt Ritter commented on SANDBOX-379:
-----------------------------------------
Hi again,
{quote}so split per-functionalities, {{DefaultBeanAccessor}} would contain the
biggest amount of tests{quote}
Not necessarily. For example we created test cases for {{getProperty()}} and
{{setProperty()}} and for {{invoke(Exact)Method}}, even though they are part of
{{BeanAccessor}} (we could have added that to BeanUtilsTest as well). I think
it would be a good idea to test all methods of a class that end the fluent API
call in one test class and just make sure that fluent API methods never return
null and throw appropriate exceptions.
So, what am I talking about? For exmaple {{setProperty()}} returns a
{{BeanPropertySetter}} on which we can continue to fluently call methods. The
same applies for {{invoke(Exact)Method()}}. In {{BeanAccessorTest}} I would
just make sure, that BeanAccessor.setProperty() never returns null and throws
appropriate Exceptions for invalid arguments. That is the reason, why I added
BeanUtilsTest in the first place. It is supposed to make sure, that changes to
BeanUtils will never break the chain of fluent calls (although you were right,
when you said, that it does not add much regarding the total test coverage).
Beside that I would make sure that {{describe()}}, {{cloneBean}},
{{populate()}} etc. work correct, since they end the chain of fluent calls by
returning POJOs.
Different scenarios for {{setProperty().withValue()}} are a different concern,
so we have a separated test for that. The only think that does not fit in that
schema is {{getProperty()}}. But since it is a very important functionality, I
think a separate test makes sense.
So, that's my big picture for the test environment... If you like that, I would
just move the contents of {{Jira157Test}} to {{BeanAccessorTest}} and leave the
rest unchanged.
{quote}
it's not a matter of taste, sometimes (depending on the bug) I do the same in
projects that have already been released, not in an experiment. The bug is
known and fixed in a previous version of the component, references in comments
are fine but don't see the advantage of dedicated test in a new version.
{quote}
Okay, I'll move it :)
> [BeanUtils2] Implement describe() on DefaultBeanAccessor
> ---------------------------------------------------------
>
> Key: SANDBOX-379
> URL: https://issues.apache.org/jira/browse/SANDBOX-379
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
> Affects Versions: Nightly Builds
> Reporter: Benedikt Ritter
> Attachments: SANDBOX-379.txt
>
>
> Implement the above mentioned method an corresponding unit tests
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
