You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by manuel aldana <al...@gmx.de> on 2009/02/14 00:24:01 UTC
@Property convention (private field bad for testing)
Tapestry goes for pojos which is good for testing. Further more I like
the @Property annotation which doesn't pollute my class with verbose
getters/setters.
The not so nice thing is, that when trying to test my component or page
I again end up having getters/setters. I place my tests inside the same
package as the class to be tested and private fields aren't visible there.
Why was the decision taken that fields must be private for @Property
(security reasons, so fields can't be changed directly from default
visibility -> package level)? From testing perspective this is not so nice.
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Property convention (private field bad for testing)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Sat, Feb 14, 2009 at 3:53 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, Feb 13, 2009 at 8:24 PM, manuel aldana <al...@gmx.de> wrote:
>> Why was the decision taken that fields must be private for @Property
>> (security reasons, so fields can't be changed directly from default
>> visibility -> package level)? From testing perspective this is not so nice.
>
> First of all, OOP recomends private fields for almost any situation.
> Regarding @Property, I guess it was a implementation issue. All
> Tapestry annotations must be put in private fields. If they could have
> another visibility, Tapestry would have to locate all places that use
> that field. If they're private, you only have to look at that class.
The AOP aspect of how Tapestry interacts with fields becomes
infinitely more complex if you have non-private fields.
I suspect that to support non-private fields, you would have to
jettison live class reloading and perhaps add a build stage
to do the necessary instrumenting. I'm happy with what I've got.
In t.1 (and maybe 5.0.18), there are some utility methods on the
TestBase class for setting private field values using reflection,
suitable for use
on non-instrumented classes as part of a test.
>
> If you use need field access outside the declaring class, use getters
> and setters instead of @Property or create package-private methods for
> testing purposes like Igor suggested. That's exactly what Tapestry
> does in its components.
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Property convention (private field bad for testing)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, Feb 13, 2009 at 8:24 PM, manuel aldana <al...@gmx.de> wrote:
> Why was the decision taken that fields must be private for @Property
> (security reasons, so fields can't be changed directly from default
> visibility -> package level)? From testing perspective this is not so nice.
First of all, OOP recomends private fields for almost any situation.
Regarding @Property, I guess it was a implementation issue. All
Tapestry annotations must be put in private fields. If they could have
another visibility, Tapestry would have to locate all places that use
that field. If they're private, you only have to look at that class.
If you use need field access outside the declaring class, use getters
and setters instead of @Property or create package-private methods for
testing purposes like Igor suggested. That's exactly what Tapestry
does in its components.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Property convention (private field bad for testing)
Posted by manuel aldana <al...@gmx.de>.
thanks,
I also thought about a package-private property-all inject() method, but
then I always need to pass all arguments and null-out, even if I only
want to set one property. In test class this is difficult to read (->
inject(null,null,null,value)) or I would need to provide test-internal
setter delegates (e.g. inject(bla) maps to inject(null,null,null,bla))
which is kind of cumbersome.
I guess the private modifier is for safety + visibility reasons, so we
shouldn't change this to default visibility. I guess I will go for
setters/getters now, if I want to explicitly set props in test cases.
PageTester looks very good, but in my case I just want to test inner
logic and no render results.
Igor Drobiazko schrieb:
> You can provide a single package-private setter for all properties which you
> can use in tests.
>
> @Property
> private Foo foo;
>
> @Property
> private Bar bar;
>
> @Property
> private Baz baz;
>
> void inject(Foo foo, Bar bar, Baz baz){ ... }
>
> If you test your pages with PageTester, you often don't need any setters
> because the page is rendered as in production.
> http://tapestry.apache.org/tapestry5/guide/unit-testing-pages.html
>
> On Sat, Feb 14, 2009 at 12:24 AM, manuel aldana <al...@gmx.de> wrote:
>
>
>> Tapestry goes for pojos which is good for testing. Further more I like the
>> @Property annotation which doesn't pollute my class with verbose
>> getters/setters.
>>
>> The not so nice thing is, that when trying to test my component or page I
>> again end up having getters/setters. I place my tests inside the same
>> package as the class to be tested and private fields aren't visible there.
>>
>> Why was the decision taken that fields must be private for @Property
>> (security reasons, so fields can't be changed directly from default
>> visibility -> package level)? From testing perspective this is not so nice.
>>
>> --
>> manuel aldana
>> aldana@gmx.de
>> software-engineering blog: http://www.aldana-online.de
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
--
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: @Property convention (private field bad for testing)
Posted by Igor Drobiazko <ig...@gmail.com>.
You can provide a single package-private setter for all properties which you
can use in tests.
@Property
private Foo foo;
@Property
private Bar bar;
@Property
private Baz baz;
void inject(Foo foo, Bar bar, Baz baz){ ... }
If you test your pages with PageTester, you often don't need any setters
because the page is rendered as in production.
http://tapestry.apache.org/tapestry5/guide/unit-testing-pages.html
On Sat, Feb 14, 2009 at 12:24 AM, manuel aldana <al...@gmx.de> wrote:
> Tapestry goes for pojos which is good for testing. Further more I like the
> @Property annotation which doesn't pollute my class with verbose
> getters/setters.
>
> The not so nice thing is, that when trying to test my component or page I
> again end up having getters/setters. I place my tests inside the same
> package as the class to be tested and private fields aren't visible there.
>
> Why was the decision taken that fields must be private for @Property
> (security reasons, so fields can't be changed directly from default
> visibility -> package level)? From testing perspective this is not so nice.
>
> --
> manuel aldana
> aldana@gmx.de
> software-engineering blog: http://www.aldana-online.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko