The same pattern used in the example test() method can be used in the
WebappTestCase superclass. Thus you can provide preconfigured
superclasses without requiring superclasses.
public class WebappTestCase {
public void setUpWebapp() {
webAppTester = new WebappTestCaseHelper();
webAppTester.setUpWebapp();
}
public void tearDownWebapp() {
webAppTester.tearDownWebapp();
webAppTester = null;
}
public void input(String value) {
return webAppTester.input(value);
}
[...]
}
On Tue, Jun 8, 2010 at 9:36 AM, Jakob Korherr <[email protected]> wrote:
> 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 <[email protected]>
>>
>> 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 <[email protected]>
>> 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
>
