You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kevin Menard <km...@servprise.com> on 2007/12/01 23:12:23 UTC
Testing T5 components
Hi all,
I've been trying to figure out how to test components all afternoon. In the
process I've learned quite a bit, but I've yet to figure out how to mock the
binding of parameters to values. Any pointers would be much appreciated.
Thanks,
Kevin
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Testing T5 components
Posted by Howard Lewis Ship <hl...@gmail.com>.
When I write unit tests for pages and components, I'm trying to test
what little logic is there, basically: does the component reads its
own fields (properties and parameters) and pass the right values to
its injected services? Any logic much more complex than that gets
shifted to the services layer, where its more obvious how to do good
tests.
Of course, with Selenium (or tool du jour) you should be integration
testing, to ensure that you and Tapestry agree on what data is
available and when ... and to catch things like template typos and the
like.
On Dec 2, 2007 6:26 AM, Kevin Menard <km...@servprise.com> wrote:
> Fair enough. I didn't know if that would be considered too invasive. It
> certainly would save a lot of time.
>
>
> On 12/1/07 11:10 PM, in article
> ecd0e3310712012010i38d2434ai7fb440c50603b8ab@mail.gmail.com, "Howard Lewis
> Ship" <hl...@gmail.com> wrote:
>
> > Well, you can read the field after the component logic sets it. I
> > often add package-private getters and setters to facilitate testing.
> >
> > On Dec 1, 2007 2:34 PM, Kevin Menard <km...@servprise.com> wrote:
>
> --
>
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
> www.servprise.com +1 508.892.3823 x308
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Testing T5 components
Posted by Kevin Menard <km...@servprise.com>.
Fair enough. I didn't know if that would be considered too invasive. It
certainly would save a lot of time.
On 12/1/07 11:10 PM, in article
ecd0e3310712012010i38d2434ai7fb440c50603b8ab@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> wrote:
> Well, you can read the field after the component logic sets it. I
> often add package-private getters and setters to facilitate testing.
>
> On Dec 1, 2007 2:34 PM, Kevin Menard <km...@servprise.com> wrote:
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Testing T5 components
Posted by Howard Lewis Ship <hl...@gmail.com>.
Well, you can read the field after the component logic sets it. I
often add package-private getters and setters to facilitate testing.
On Dec 1, 2007 2:34 PM, Kevin Menard <km...@servprise.com> wrote:
>
>
>
> On 12/1/07 5:25 PM, in article
> ecd0e3310712011425j814b1fbk316504490fad90a3@mail.gmail.com, "Howard Lewis
> Ship" <hl...@gmail.com> wrote:
>
> > For unit testing, you don't ... you just let the parameters act like
> > normal fields.
>
> Hmm . . . Okay, but how do you test that a component has actually modified
> the value?
>
> E.g., I was looking at DateField for TAPESTRY-1893 and processSubmission()
> overwrites the existing reference. So, I can't even check that the value I
> had originally has been changed, because it will not have been. I was
> hoping being able to set up a binding would allow me to do this.
>
> --
>
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
> www.servprise.com +1 508.892.3823 x308
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Testing T5 components
Posted by Kevin Menard <km...@servprise.com>.
On 12/1/07 5:25 PM, in article
ecd0e3310712011425j814b1fbk316504490fad90a3@mail.gmail.com, "Howard Lewis
Ship" <hl...@gmail.com> wrote:
> For unit testing, you don't ... you just let the parameters act like
> normal fields.
Hmm . . . Okay, but how do you test that a component has actually modified
the value?
E.g., I was looking at DateField for TAPESTRY-1893 and processSubmission()
overwrites the existing reference. So, I can't even check that the value I
had originally has been changed, because it will not have been. I was
hoping being able to set up a binding would allow me to do this.
--
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com +1 508.892.3823 x308
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Testing T5 components
Posted by Howard Lewis Ship <hl...@gmail.com>.
For unit testing, you don't ... you just let the parameters act like
normal fields.
For integration testing ... you let Tapestry set up the
infrastructure, whether as part of PageTester or when testing using
Selenium or a similar tool.
The only thing I tend to mock is ComponentResources.isBound().
On Dec 1, 2007 2:12 PM, Kevin Menard <km...@servprise.com> wrote:
> Hi all,
>
> I've been trying to figure out how to test components all afternoon. In the
> process I've learned quite a bit, but I've yet to figure out how to mock the
> binding of parameters to values. Any pointers would be much appreciated.
>
> Thanks,
> Kevin
>
> --
> Kevin Menard
> Servprise International, Inc.
> Remote reboot & power control for network equipment
> www.servprise.com +1 508.892.3823 x308
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org