commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedikt Ritter (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SANDBOX-379) [BeanUtils2] Implement describe() on DefaultBeanAccessor
Date Thu, 02 Feb 2012 11:15:53 GMT

    [ 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

        

Mime
View raw message