Hi Mike,
Thanks for looking at this!
The input().into() will most likely just delegate to HtmlUnit to set the
values on the current page. Thus inputting into a non-rendered field will
not be possible.
Yes, actually Gerhard and I are currently talking about this. On the one
hand we want to have the chance to provide preconfigured super-classes
(mostly for extension testing - see ExtensionTestCase on the wiki page) and
on the other hand we don't want to use super-classes at all. That's why
Gerhard suggested something like
@Configuration(SomeConfigurationClass.class) instead of inheritance. In this
way we would also be able to provide preconfigured configurations.
Furthermore the input() and assert() methods would have to be moved to some
helper class, right.
I will update the wiki page with this information.
Do you have some other ideas about it?
Regards,
Jakob
2010/6/8 Mike Kienenberger <mkien...@gmail.com>
> Looks very interesting.
>
>
> Can you add an example test showing what it would look like to test if
> a component was rendered? Design note: attempting to input().into()
> a non-rendered component (or otherwise manipulate a non-rendered
> component from the tests) should raise an assertion.
>
>
> Is it possible to design the WebappTestCase class to delegate calls to
> another class so that tests do not have to extend WebappTestCase, or
> will this cause problems with the annotation configuration? There
> are other testing frameworks out there that already require a specific
> TestCase superclass, so this should be avoided if possible.
>
> Ideally, you would have a WebappTestCaseHelper class with the
> functionality of the current WebappTestCase, then have a new
> WebappTestCase delegate to WebappTestCaseHelper.
>
> Then if you need to extend a different testcase base, you could work
> with WebappTestCaseHelper directly instead.
>
> For example, if WebappTestCaseHelper were static,
>
> import static WebappTestCaseHelper.input;
>
> public void setup() {
> WebappTestCaseHelper.setUpWebapp();
> }
>
> public void tearDown() {
> WebappTestCaseHelper.tearDownWebapp();
> }
>
> public void test() {
> input("value").into("id");
> }
>
> or if WebappTestCaseHelper were an instance:
>
>
> public WebappTestCaseHelper webAppTester;
>
> public void setup() {
> webAppTester = new WebappTestCaseHelper();
> webAppTester.setUpWebapp();
> }
>
> public void tearDown() {
> webAppTester.tearDownWebapp();
> webAppTester = null;
> }
>
> public void test() {
> webAppTester.input("value").into("id");
> }
>
>
> On Mon, Jun 7, 2010 at 10:00 AM, Jakob Korherr <jakob.korh...@gmail.com>
> wrote:
> > Hi guys,
> >
> > Cosmin, Gerhard and I have been working on an initial API proposal for
> the
> > GSoC project "Automated webapptests for MyFacescore + extensions". You
> can
> > find the proposal in the MyFaces wiki at
> > http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
> >
> > With the help of this API it will be possible to run automated tests
> against
> > the real JSF implementation running in a container (e.g. Jetty).
> >
> > It would be very great if you could take a look at the proposal and tell
> us
> > what you think about it or how you would change it.
> >
> > Thanks in advance!
> >
> > Regards,
> > Jakob
> >
> > --
> > Jakob Korherr
> >
> > blog: http://www.jakobk.com
> > twitter: http://twitter.com/jakobkorherr
> > work: http://www.irian.at
> >
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
