Paul,
thanks for the help on this. I'll try it out soon.
On why I'm using the page class : I guess this goes back to using POJOs
for unit testing. What I mean is that in my tapestry page class I have a
couple of methods (e.g. like setupRender , event handlers) which mean
something special for tapestry, but still do things in the page that I want
to be able to be able to test that that they do what they're supposed to.
Particularly when "unit testing" the pages (that is, isolating the page as a
unit, injecting mock dependencies into it), there is little to be gained by
allowing tapestry to instrument the page class : all I care is that my page
has a method called "foo()", and that when I call page.foo(), all the right
collaborators are called and then I can assert on the postconditions of the
method. If my method implementation depends on some tapestry class that is
typically instrumented by the framework, I'd still probably want to have a
mock implementation during the test so that I can control what it does (and
doesn't go into the rabbit hole of calling a whole bunch of other T5 code)
The approach that you describe w/ using the requestPageCache will
probably work but it is somewhat more difficult than it needs to for a
newcomer to the framework that they couldn't just instantiate the page and
invoke methods on the object for testing. More accurately, as a user I can
instantiate the page and invoke methods on it, but it is exceedingly hard to
do the T5 IoC magic on the page (e.g. inject the dependencies) w/o jumping
through some major hoops (e.g. creating a mock T5 IoC repository for each
test that would make the services I want available if/when I call
tester.injectInto(page).
It seems like a very natural enhancement for Testify : you already have
ways of declaring test specific services using @ForComponents that are
injected into pages/components by the setup methods. Why not populate
whatever needs to be populated w/ the same services so that injectInto works
for injecting services/dependencies into the class. Alternatively, having an
easy way to get to the page class from the tester (e.g.
tester.getPageClass()) that does what you describe would probably do just as
well.
Regards,
Alex K
On Tue, Feb 2, 2010 at 9:27 AM, Paul Field <paul.fi...@db.com> wrote:
> akochnev <akoch...@gmail.com> wrote on 31/01/2010 11:26:53:
>
> > The next thing I'm trying to work out is use Testify for unit-like
> > testing. The idea was that I could possibly instantiate the page class
> > myself (e.g. w/o having to ask the tester to render the page), inject
> the
> > dependencies (using tester.injectInto(pageInstance) ) that are needed
> for a
> > particular method and then just invoke the method.
>
> The injectInto() method is designed to populate fields in a test *before*
> any of the setup is done - so it doesn't really expect to work with the
> @ForComponents annotations.
>
> You could let Tapestry do the instantiation of the page for you. I think
> this will work (although it uses internal services so it might work now
> but not in a future Tapestry version):
>
> @Inject
> private RequestPageCache cache;
>
> public void test() {
> StupidPage page =
>
> (StupidPage)cache.get("mypages/stupidPage").getRootElement().getComponent();
> page.myMethod();
> }
>
> This potentially has the advantage that all the transformations have been
> done on the class - so it behaves more like the page actually will.
>
> Out of interest, what kind of tests need the instance of the page class? I
> haven't felt the need so far so I wonder if I'm missing out on something
> :-)
>
> Paul
>
>
>
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
