Hi Rudy, Yes, of course. This will certainly be an important issue we have to address, but I think we will be on the safe side by starting one container for multiple tests with the same dependencies and then deploying each test case as an own WAR. This is the way Arquillian does it and it is not that slow ;)
The @Dependency stuff will resolve the dependencies itself, because there will not be a POM for each test case. You see, the background is that you can use e.g. MyFaces core 2.0 with the "old" expression language, or with the new EL 2.2 and we want to be able to test both scenarios. We have to see if we really want to use CDI or just use their @Inject annotation for the test case. Actually I don't know, but I guess CDI can be used with any web-framework, including JSF 1.1, because the CDI core is not JSF specific. Regards, Jakob 2010/6/8 Rudy De Busscher <[email protected]> > looks promising, will speed be of any considiration? Assembling the > resources and starting op the web container could be a major impact. I > prefer functionality above execution time but it has some limits. > > The @dependency annotation, is it resolving the dependencies itself or just > refering to the maven POM info? And if it resolves the dependencies on his > own, what is the relation between maven and @dependency ? > > @Inject -> What restrictions are implied due to the use of CDI. Can > OpenWebBeans/Weld be used with JSF 1.1 ? (A quick search did not give me any > clue) > > > regards > Rudy. > > > > On 8 June 2010 16:13, Jakob Korherr <[email protected]> wrote: > >> Yes, right! >> >> I adapted the wiki page and added this as the second idea. >> >> >> Regards, >> Jakob >> >> 2010/6/8 Mike Kienenberger <[email protected]> >> >>> 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 >>> > >>> >> >> >> >> -- >> 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
