Re: [GSoC] Automated webapp tests project
Hi,
I also did some tests and had to make a small modification so that it finds
my custom maven repository (defined in the settings.xml). For the rest, it
seems to work great.
I can add that code after the integration is done.
regards
rudy.
On 17 August 2010 22:02, Jakob Korherr jakob.korh...@gmail.com wrote:
Hi Leo,
After the integration, we can do that. I would like to have this too :)
Regards,
Jakob
2010/8/17 Leonardo Uribe lu4...@gmail.com
Hi
Good to know that. I'll take a look at this one. I would like to have a
test suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I wanted to let you
know about the progress and the current state of the Automated webapp tests
for MyFacescore and extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google code) on:
- http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
- https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki, including small
changes like introducing @Tester and @Assertable instead of @Inject
for the resource injection configuration. The @Tester will inject an
WebappTester instance that will provide all required functionality, and
@Assertable to inject proxy instances for assertions.
Also an @ConfigurationTestSuite configuration was provided, where the
user of the API can specify a list of configurations and the API will run
the test case with all the configs, meaning an n configured test case will
generate n tests for the same test instance but with each of the specified
configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId) and
expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall() that I
overlooked, but this should be functional by the end of this week. Other
drawbacks of the project are that I couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with @Deployment and if such
a method is not provided it fails the test run. Another inconvenience is
that, for the embaded Tomcat container, Arquillian requires, for now, a
servlet mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly appreciate any feedback, comments or suggestions on the
project and the implementation.
Regards,
Cosmin
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [GSoC] Automated webapp tests project
Hi I added meta logging facilities to _ExtLang.js a while ago I have
been using this mainly for manual testing with Selenium as afterthought.
It might be a base to start off for the ajax stuff.
What it does is to be able to log into a console if it exists,
and also to a div with a certain id if this one exists in the dom tree.
Also there is a small unit testing javascript class in UnitTest.js
which takes care of asserts on top of it the way junit does.
Again currently only used by me internally.
We might take that one as a small base for testing on the client side in
conjunction with selenium.
Werner
Am 18.08.10 09:08, schrieb Rudy De Busscher:
Hi,
I also did some tests and had to make a small modification so that it
finds my custom maven repository (defined in the settings.xml). For the
rest, it seems to work great.
I can add that code after the integration is done.
regards
rudy.
On 17 August 2010 22:02, Jakob Korherr jakob.korh...@gmail.com
mailto:jakob.korh...@gmail.com wrote:
Hi Leo,
After the integration, we can do that. I would like to have this too :)
Regards,
Jakob
2010/8/17 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com
Hi
Good to know that. I'll take a look at this one. I would like to
have a test suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
mailto:cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I
wanted to let you know about the progress and the current
state of the Automated webapp tests for MyFacescore and
extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google
code) on:
* http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
*
https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki,
including small changes like introducing @Tester and
@Assertable instead of @Inject for the resource
injection configuration. The @Tester will inject an
WebappTester instance that will provide all required
functionality, and @Assertable to inject proxy instances
for assertions.
Also an @ConfigurationTestSuite configuration was
provided, where the user of the API can specify a list of
configurations and the API will run the test case with all
the configs, meaning an n configured test case will
generate n tests for the same test instance but with each
of the specified configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId)
and expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall()
that I overlooked, but this should be functional by the end
of this week. Other drawbacks of the project are that I
couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with
@Deployment and if such a method is not provided it fails
the test run. Another inconvenience is that, for the embaded
Tomcat container, Arquillian requires, for now, a servlet
mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly appreciate any feedback, comments or
suggestions on the project and the implementation.
Regards,
Cosmin
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [GSoC] Automated webapp tests project
Hi,
That's really great Rudy. Thanks for trying it out :)
Frankly I would say that the current version is somewhere pre-pre-alpha,
because there is a lot of stuff that has to be improved (like e.g. your
custom maven repo), but the code from Cosmin is a solid base and we can
totally build upon it!
Cosmin told me he is willing to work on it after GSoC and the first thing he
will do is providing a DevDoc wiki page. There we can post
problems/suggestions/improvements. Furthermore we can use JIRA (maybe as a
new project - WEBAPPTESTS ?).
Werner, I think we can do a lot of your tests using the
automated-webapp-tests. I am looking forward to trying it out :)
Regards,
Jakob
2010/8/18 Werner Punz werner.p...@gmail.com
Hi I added meta logging facilities to _ExtLang.js a while ago I have been
using this mainly for manual testing with Selenium as afterthought. It might
be a base to start off for the ajax stuff.
What it does is to be able to log into a console if it exists,
and also to a div with a certain id if this one exists in the dom tree.
Also there is a small unit testing javascript class in UnitTest.js
which takes care of asserts on top of it the way junit does.
Again currently only used by me internally.
We might take that one as a small base for testing on the client side in
conjunction with selenium.
Werner
Am 18.08.10 09:08, schrieb Rudy De Busscher:
Hi,
I also did some tests and had to make a small modification so that it
finds my custom maven repository (defined in the settings.xml). For the
rest, it seems to work great.
I can add that code after the integration is done.
regards
rudy.
On 17 August 2010 22:02, Jakob Korherr jakob.korh...@gmail.com
mailto:jakob.korh...@gmail.com wrote:
Hi Leo,
After the integration, we can do that. I would like to have this too :)
Regards,
Jakob
2010/8/17 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com
Hi
Good to know that. I'll take a look at this one. I would like to
have a test suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
mailto:cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I
wanted to let you know about the progress and the current
state of the Automated webapp tests for MyFacescore and
extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google
code) on:
* http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
*
https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki,
including small changes like introducing @Tester and
@Assertable instead of @Inject for the resource
injection configuration. The @Tester will inject an
WebappTester instance that will provide all required
functionality, and @Assertable to inject proxy instances
for assertions.
Also an @ConfigurationTestSuite configuration was
provided, where the user of the API can specify a list of
configurations and the API will run the test case with all
the configs, meaning an n configured test case will
generate n tests for the same test instance but with each
of the specified configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId)
and expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall()
that I overlooked, but this should be functional by the end
of this week. Other drawbacks of the project are that I
couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with
@Deployment and if such a method is not provided it fails
the test run. Another inconvenience is that, for the embaded
Tomcat container, Arquillian requires, for now, a servlet
mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly
Re: [GSoC] Automated webapp tests project
Hi,
Thanks for your feedback and suggestions, and special thanks to Jakob, for a
great collaboration, and Gerhard my mentors for this project. GSoC codding
is over, and it would be my pleasure to continue working on this project
within MyFaces. So, as Jakob mentioned, I will initially provide a wiki
page with a more detailed description of the project, the drawbacks and the
improvements needed and you are very welcomed to input any suggestions.
Yes, this is a pre-pre-alpha version of the API, but I'm looking forward
continuing it and hope we can make it a great testing framework.
Cheers,
Cosmin
On Wed, Aug 18, 2010 at 12:21 PM, Jakob Korherr jakob.korh...@gmail.comwrote:
Hi,
That's really great Rudy. Thanks for trying it out :)
Frankly I would say that the current version is somewhere pre-pre-alpha,
because there is a lot of stuff that has to be improved (like e.g. your
custom maven repo), but the code from Cosmin is a solid base and we can
totally build upon it!
Cosmin told me he is willing to work on it after GSoC and the first thing
he will do is providing a DevDoc wiki page. There we can post
problems/suggestions/improvements. Furthermore we can use JIRA (maybe as a
new project - WEBAPPTESTS ?).
Werner, I think we can do a lot of your tests using the
automated-webapp-tests. I am looking forward to trying it out :)
Regards,
Jakob
2010/8/18 Werner Punz werner.p...@gmail.com
Hi I added meta logging facilities to _ExtLang.js a while ago I have been
using this mainly for manual testing with Selenium as afterthought. It might
be a base to start off for the ajax stuff.
What it does is to be able to log into a console if it exists,
and also to a div with a certain id if this one exists in the dom tree.
Also there is a small unit testing javascript class in UnitTest.js
which takes care of asserts on top of it the way junit does.
Again currently only used by me internally.
We might take that one as a small base for testing on the client side in
conjunction with selenium.
Werner
Am 18.08.10 09:08, schrieb Rudy De Busscher:
Hi,
I also did some tests and had to make a small modification so that it
finds my custom maven repository (defined in the settings.xml). For the
rest, it seems to work great.
I can add that code after the integration is done.
regards
rudy.
On 17 August 2010 22:02, Jakob Korherr jakob.korh...@gmail.com
mailto:jakob.korh...@gmail.com wrote:
Hi Leo,
After the integration, we can do that. I would like to have this too
:)
Regards,
Jakob
2010/8/17 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com
Hi
Good to know that. I'll take a look at this one. I would like to
have a test suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
mailto:cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I
wanted to let you know about the progress and the current
state of the Automated webapp tests for MyFacescore and
extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google
code) on:
* http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
*
https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki,
including small changes like introducing @Tester and
@Assertable instead of @Inject for the resource
injection configuration. The @Tester will inject an
WebappTester instance that will provide all required
functionality, and @Assertable to inject proxy instances
for assertions.
Also an @ConfigurationTestSuite configuration was
provided, where the user of the API can specify a list of
configurations and the API will run the test case with all
the configs, meaning an n configured test case will
generate n tests for the same test instance but with each
of the specified configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId)
and expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall()
that I overlooked, but this should be functional by the end
of this week. Other drawbacks of the project are that I
couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking
Re: [GSoC] Automated webapp tests project
Hi Cosmin,
Thanks a lot for your great work! I already tried it out a couple of times
and it works really great.
I will integrate the code into the MyFaces codebase after GSoC ends so that
we all can start working on this framework. Later, when we have the first
releaseable version in place, we can begin to write MyFaces core (and
tomahawk, codi, ext-val, trinidad, tobago,) tests with it, and this will
be kick-ass!
Regards,
Jakob
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I wanted to let you
know about the progress and the current state of the Automated webapp tests
for MyFacescore and extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google code) on:
- http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
- https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki, including small
changes like introducing @Tester and @Assertable instead of @Inject
for the resource injection configuration. The @Tester will inject an
WebappTester instance that will provide all required functionality, and
@Assertable to inject proxy instances for assertions.
Also an @ConfigurationTestSuite configuration was provided, where the
user of the API can specify a list of configurations and the API will run
the test case with all the configs, meaning an n configured test case will
generate n tests for the same test instance but with each of the specified
configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId) and
expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall() that I
overlooked, but this should be functional by the end of this week. Other
drawbacks of the project are that I couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with @Deployment and if such a
method is not provided it fails the test run. Another inconvenience is that,
for the embaded Tomcat container, Arquillian requires, for now, a servlet
mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly appreciate any feedback, comments or suggestions on the
project and the implementation.
Regards,
Cosmin
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [GSoC] Automated webapp tests project
Hi
Good to know that. I'll take a look at this one. I would like to have a test
suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I wanted to let you
know about the progress and the current state of the Automated webapp tests
for MyFacescore and extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google code) on:
- http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
- https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki, including small
changes like introducing @Tester and @Assertable instead of @Inject
for the resource injection configuration. The @Tester will inject an
WebappTester instance that will provide all required functionality, and
@Assertable to inject proxy instances for assertions.
Also an @ConfigurationTestSuite configuration was provided, where the
user of the API can specify a list of configurations and the API will run
the test case with all the configs, meaning an n configured test case will
generate n tests for the same test instance but with each of the specified
configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId) and
expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall() that I
overlooked, but this should be functional by the end of this week. Other
drawbacks of the project are that I couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with @Deployment and if such a
method is not provided it fails the test run. Another inconvenience is that,
for the embaded Tomcat container, Arquillian requires, for now, a servlet
mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly appreciate any feedback, comments or suggestions on the
project and the implementation.
Regards,
Cosmin
Re: [GSoC] Automated webapp tests project
Hi Leo,
After the integration, we can do that. I would like to have this too :)
Regards,
Jakob
2010/8/17 Leonardo Uribe lu4...@gmail.com
Hi
Good to know that. I'll take a look at this one. I would like to have a
test suite for flash scope and ajax stuff.
regards,
Leonardo Uribe
2010/8/10 Martinconi Cosmin cosmin.martinc...@codebeat.ro
Hi,
The GSoC program for this year is almost finished and I wanted to let you
know about the progress and the current state of the Automated webapp tests
for MyFacescore and extensions, my project for this GSoC.
You can follow the API and the implementation(SVN google code) on:
- http://wiki.apache.org/myfaces/AutomatedWebappTestsAPI
- https://gsoc2010-automated-myfaces-tests.googlecode.com/svn/trunk/
The API that I have followed is the one from the wiki, including small
changes like introducing @Tester and @Assertable instead of @Inject
for the resource injection configuration. The @Tester will inject an
WebappTester instance that will provide all required functionality, and
@Assertable to inject proxy instances for assertions.
Also an @ConfigurationTestSuite configuration was provided, where the
user of the API can specify a list of configurations and the API will run
the test case with all the configs, meaning an n configured test case will
generate n tests for the same test instance but with each of the specified
configs.
The API provides the following actions: click(buttonId),
input(string).into(fieldId); and the assertions:
assertThat(methodCall/ELexpression).is(Object).before/after(PhaseId) and
expectCall(methodCall/ELexpression).in(PhaseId)
I am currently working on some issues regarding expectCall() that I
overlooked, but this should be functional by the end of this week. Other
drawbacks of the project are that I couldn't get rid of the method:
@Deployment
public static Archive? createDeployment() {
return webappTestCase.createArchive(null);
}
Arquillian is looking for a method annotated with @Deployment and if such
a method is not provided it fails the test run. Another inconvenience is
that, for the embaded Tomcat container, Arquillian requires, for now, a
servlet mapping in the web.xml of the testing webapp, like:
servlet
servlet-nameServletTestRunner/servlet-name
servlet-classorg.apache.myfaces.test.webapp.api.runner.WebappServletTestRunner/servlet-class
/servlet
servlet-mapping
servlet-nameServletTestRunner/servlet-name
url-pattern/ArquillianServletRunner/url-pattern
/servlet-mapping
I would highly appreciate any feedback, comments or suggestions on the
project and the implementation.
Regards,
Cosmin
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [GSoC] Automated webapp tests API draft
Hi Leo, First of all it is very great to have you on board with MyFaces-test stuff. I saw that you opened an issue about creating a site on myfaces.apache.org for myfaces-test, which is just great!! I think, after the GSoC project, we should have two modules of myfaces-test. The first one providing mock classes and test base classes (or even better: test helpers and TestRunners for the use in @RunWith) and the second one providing the automated webapp tests API. However I think you got a somehow wrong idea about the GSoC project. This API really is designed for writing JUnit tests (and thus beeing able to set breakpoints in your IDE). It just does not test only one part of the implementation (like e.g. state saving, rendering,..), but a whole use case. This means that you first write a normal JUnit test case and when this test case is executed, a container will automatically be started (with some given config) and the test case will be executed in the container environment. Thus beeing able to test against the real implementation rather than against the mock classes. You can take a look at the JBoss Arquillian project, which is related to this stuff. I already told Cosmin to create a Google code project for this GSoC project, so we will soon be able to keep track of it. I really do hope we will be able to create something that not only we can use internally to test MyFaces core and tomahawk, but also something that users can use to test their JSF applications. Regards, Jakob 2010/6/18 Leonardo Uribe lu4...@gmail.com Hi I think in my personal opinion the target of myfaces-test and what is proposed in this project are two different things. - myfaces-test aims to provide a jsf test environment for artifacts like components, attached objects(converters, validators ) or things related to myfaces core itself (test state saving stuff, if some algorithm is working or not,). The usual test case is for example the user wants to know if the component do something, or if the renderer output some expected output. - The proposal for GSOC aims to provide a jsf test environment that will use different containers and the objective is make test that could be run against different server configurations (for example, run some tests against different web.xml configurations). Really what I like about use myfaces-test is the ability to run the tests using junit in eclipse and set breakpoints. It is very, very simple, so if it is necessary to make tests about some component or some feature in myfaces core, in my opinion the preferred option will be use myfaces-test. Sometimes it is not required to test in different containers or server configuration to know if the code works or not, so the important thing to keep in mind is use the right tool for the job. I would like to have the ability to set breakpoints with eclipse or other IDE, at least on a single container with this tool, but I think as long as it can do what is expected it is ok. Let's see what happen with this project. regards, Leonardo 2010/6/18 Gerhard Petracek gerhard.petra...@gmail.com hi, imo the mentioned gsoc project should provide an easy to use api which reduces the amount of test-code to a minimum. the tests should run in the embedded versions of the available containers. therefore it's possible to test jsf applications, component libs, extensions,... with real jsf implementations and without using mocks for jsf artifacts. furthermore, it should be possible to run the same tests with different servers as well as server configurations. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/6/18 Leonardo Uribe lu4...@gmail.com Hi I have checked the status of myfaces testing stuff and I did a list of the oportunities to make myfaces even better. - Enhance myfaces-test project: In that project we have just moved shale-test stuff and did some updates/fixes to make it work in jsf 2.0. But it is becoming more critical to really update/enhance the code, because it is becoming very common to add custom stuff on myfaces-impl to make some tests work. - Myfaces-test specific code: Since now we have facelets inside myfaces, one possibility is create a jar file that works with myfaces core code and make complex tests that requires run facelets VDL code. Now in myfaces core we have a test suite for composite components that uses that kind of stuff, but we can't do that type of tests outside myfaces (for example a component library). I would like to run a full request lifecycle using mock objects without deal with a servlet container, just write my JUnit test and that's it. - Test app for myfaces core stuff that we can't test using junit: There are some new stuff added to myfaces core 2.0 that we just can't test it with junit + myfaces test. Some examples are flash
Re: [GSoC] Automated webapp tests API draft
hi, imo the mentioned gsoc project should provide an easy to use api which reduces the amount of test-code to a minimum. the tests should run in the embedded versions of the available containers. therefore it's possible to test jsf applications, component libs, extensions,... with real jsf implementations and without using mocks for jsf artifacts. furthermore, it should be possible to run the same tests with different servers as well as server configurations. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/6/18 Leonardo Uribe lu4...@gmail.com Hi I have checked the status of myfaces testing stuff and I did a list of the oportunities to make myfaces even better. - Enhance myfaces-test project: In that project we have just moved shale-test stuff and did some updates/fixes to make it work in jsf 2.0. But it is becoming more critical to really update/enhance the code, because it is becoming very common to add custom stuff on myfaces-impl to make some tests work. - Myfaces-test specific code: Since now we have facelets inside myfaces, one possibility is create a jar file that works with myfaces core code and make complex tests that requires run facelets VDL code. Now in myfaces core we have a test suite for composite components that uses that kind of stuff, but we can't do that type of tests outside myfaces (for example a component library). I would like to run a full request lifecycle using mock objects without deal with a servlet container, just write my JUnit test and that's it. - Test app for myfaces core stuff that we can't test using junit: There are some new stuff added to myfaces core 2.0 that we just can't test it with junit + myfaces test. Some examples are flash scope, ajax, combinations of post-redirect-get pattern. It is necessary to create some tests for this stuff to enhance stability of these features. In my understanding, the direction that took this GSOC project is different. The objective is create a new API more focused in test web applications deployed on a container, and use myfaces specific code to bridge between the test and myfaces implementation running in the container (at this point it is not very clear the steps to make a test run). It looks good, so I'll keep an eye on it. I suppose that the resulting code could be a new module of myfaces-test. I hope as the name of this project suggest, one contribution will be a automated webapp for test myfaces core 2.0, but it seems more important in the future have a new api for testing. Right now, almost all code is in place for tomahawk core20 project, but it is necessary to test it before make any release. So I'll start to work in the first two ideas, aiming to do an official release of myfaces-test project, and I'll keep an eye on the results of the GSOC project. It could be good to know if some svn repo is used to publish the advance of this project (for example http://code.google.com). regards, Leonardo Uribe
Re: [GSoC] Automated webapp tests API draft
Hi I think in my personal opinion the target of myfaces-test and what is proposed in this project are two different things. - myfaces-test aims to provide a jsf test environment for artifacts like components, attached objects(converters, validators ) or things related to myfaces core itself (test state saving stuff, if some algorithm is working or not,). The usual test case is for example the user wants to know if the component do something, or if the renderer output some expected output. - The proposal for GSOC aims to provide a jsf test environment that will use different containers and the objective is make test that could be run against different server configurations (for example, run some tests against different web.xml configurations). Really what I like about use myfaces-test is the ability to run the tests using junit in eclipse and set breakpoints. It is very, very simple, so if it is necessary to make tests about some component or some feature in myfaces core, in my opinion the preferred option will be use myfaces-test. Sometimes it is not required to test in different containers or server configuration to know if the code works or not, so the important thing to keep in mind is use the right tool for the job. I would like to have the ability to set breakpoints with eclipse or other IDE, at least on a single container with this tool, but I think as long as it can do what is expected it is ok. Let's see what happen with this project. regards, Leonardo 2010/6/18 Gerhard Petracek gerhard.petra...@gmail.com hi, imo the mentioned gsoc project should provide an easy to use api which reduces the amount of test-code to a minimum. the tests should run in the embedded versions of the available containers. therefore it's possible to test jsf applications, component libs, extensions,... with real jsf implementations and without using mocks for jsf artifacts. furthermore, it should be possible to run the same tests with different servers as well as server configurations. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/6/18 Leonardo Uribe lu4...@gmail.com Hi I have checked the status of myfaces testing stuff and I did a list of the oportunities to make myfaces even better. - Enhance myfaces-test project: In that project we have just moved shale-test stuff and did some updates/fixes to make it work in jsf 2.0. But it is becoming more critical to really update/enhance the code, because it is becoming very common to add custom stuff on myfaces-impl to make some tests work. - Myfaces-test specific code: Since now we have facelets inside myfaces, one possibility is create a jar file that works with myfaces core code and make complex tests that requires run facelets VDL code. Now in myfaces core we have a test suite for composite components that uses that kind of stuff, but we can't do that type of tests outside myfaces (for example a component library). I would like to run a full request lifecycle using mock objects without deal with a servlet container, just write my JUnit test and that's it. - Test app for myfaces core stuff that we can't test using junit: There are some new stuff added to myfaces core 2.0 that we just can't test it with junit + myfaces test. Some examples are flash scope, ajax, combinations of post-redirect-get pattern. It is necessary to create some tests for this stuff to enhance stability of these features. In my understanding, the direction that took this GSOC project is different. The objective is create a new API more focused in test web applications deployed on a container, and use myfaces specific code to bridge between the test and myfaces implementation running in the container (at this point it is not very clear the steps to make a test run). It looks good, so I'll keep an eye on it. I suppose that the resulting code could be a new module of myfaces-test. I hope as the name of this project suggest, one contribution will be a automated webapp for test myfaces core 2.0, but it seems more important in the future have a new api for testing. Right now, almost all code is in place for tomahawk core20 project, but it is necessary to test it before make any release. So I'll start to work in the first two ideas, aiming to do an official release of myfaces-test project, and I'll keep an eye on the results of the GSOC project. It could be good to know if some svn repo is used to publish the advance of this project (for example http://code.google.com). regards, Leonardo Uribe
Re: [GSoC] Automated webapp tests API draft
Hi I have checked the status of myfaces testing stuff and I did a list of the oportunities to make myfaces even better. - Enhance myfaces-test project: In that project we have just moved shale-test stuff and did some updates/fixes to make it work in jsf 2.0. But it is becoming more critical to really update/enhance the code, because it is becoming very common to add custom stuff on myfaces-impl to make some tests work. - Myfaces-test specific code: Since now we have facelets inside myfaces, one possibility is create a jar file that works with myfaces core code and make complex tests that requires run facelets VDL code. Now in myfaces core we have a test suite for composite components that uses that kind of stuff, but we can't do that type of tests outside myfaces (for example a component library). I would like to run a full request lifecycle using mock objects without deal with a servlet container, just write my JUnit test and that's it. - Test app for myfaces core stuff that we can't test using junit: There are some new stuff added to myfaces core 2.0 that we just can't test it with junit + myfaces test. Some examples are flash scope, ajax, combinations of post-redirect-get pattern. It is necessary to create some tests for this stuff to enhance stability of these features. In my understanding, the direction that took this GSOC project is different. The objective is create a new API more focused in test web applications deployed on a container, and use myfaces specific code to bridge between the test and myfaces implementation running in the container (at this point it is not very clear the steps to make a test run). It looks good, so I'll keep an eye on it. I suppose that the resulting code could be a new module of myfaces-test. I hope as the name of this project suggest, one contribution will be a automated webapp for test myfaces core 2.0, but it seems more important in the future have a new api for testing. Right now, almost all code is in place for tomahawk core20 project, but it is necessary to test it before make any release. So I'll start to work in the first two ideas, aiming to do an official release of myfaces-test project, and I'll keep an eye on the results of the GSOC project. It could be good to know if some svn repo is used to publish the advance of this project (for example http://code.google.com). regards, Leonardo Uribe
Re: [GSoC] Automated webapp tests API draft
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 rdebussc...@gmail.com
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 jakob.korh...@gmail.com wrote:
Yes, right!
I adapted the wiki page and added this as the second idea.
Regards,
Jakob
2010/6/8 Mike Kienenberger mkien...@gmail.com
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 jakob.korh...@gmail.com
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 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() {
Re: [GSoC] Automated webapp tests API draft
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
Re: [GSoC] Automated webapp tests API draft
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
Re: [GSoC] Automated webapp tests API draft
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 jakob.korh...@gmail.com 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 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
Re: [GSoC] Automated webapp tests API draft
Yes, right!
I adapted the wiki page and added this as the second idea.
Regards,
Jakob
2010/6/8 Mike Kienenberger mkien...@gmail.com
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 jakob.korh...@gmail.com
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 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
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [GSoC] Automated webapp tests API draft
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 jakob.korh...@gmail.com wrote:
Yes, right!
I adapted the wiki page and added this as the second idea.
Regards,
Jakob
2010/6/8 Mike Kienenberger mkien...@gmail.com
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 jakob.korh...@gmail.com
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 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
Re: [GSoC] Automated webapp tests
Hi Just one comment, the test webapp here: http://svn.apache.org/repos/asf/myfaces/current20/test-webapp/ has a very simple integration test that runs with maven and use HtmlUnit. It has profiles that runs them with jetty and tomcat(using maven cargo plugin) I also did something similar on http://svn.apache.org/repos/asf/myfaces/orchestra/trunk/examples to test orchestra in different configurations. The long term plan is add here all tests that we can't do with myfaces-test and JUnit. This include test flash scope, ajax stuff, f:metadata and f:viewParam. It could be good to add more test profiles for other servers. The thing that likes me about that setup is it is possible to set a break points for that kind of tests from eclipse and no extra configuration is required. In other side, tobago uses selenium for testing, maybe we can reuse code from there. regards, Leonardo Uribe 2010/4/8 Mike Kienenberger mkien...@gmail.com You could note that in the proposal :) On Thu, Apr 8, 2010 at 8:28 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Selenium seems to keep coming up here again and again, but the main problem about it is that you need a browser to run the tests and that is what we don't want. We want to be able to include the tests in every maven build and thus also on the apache build server and we certainly can't use a browser there. Regards, Jakob 2010/4/8 Jan-Kees van Andel jankeesvanan...@gmail.com You can use the Selenium RC Server [1] to host the browser. You can then remotely invoke this server from your Maven build. The Maven build then doesn't need a browser. (but you're right, Selenium needs a browser *somewhere*) Regards, Jan-Kees [1] http://seleniumhq.org/projects/remote-control/ 2010/4/8 Matthias Wessendorf mat...@apache.org Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.comwrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin
Re: [GSoC] Automated webapp tests
Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
You can use the Selenium RC Server [1] to host the browser. You can then remotely invoke this server from your Maven build. The Maven build then doesn't need a browser. (but you're right, Selenium needs a browser *somewhere*) Regards, Jan-Kees [1] http://seleniumhq.org/projects/remote-control/ 2010/4/8 Matthias Wessendorf mat...@apache.org Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
Selenium seems to keep coming up here again and again, but the main problem about it is that you need a browser to run the tests and that is what we don't want. We want to be able to include the tests in every maven build and thus also on the apache build server and we certainly can't use a browser there. Regards, Jakob 2010/4/8 Jan-Kees van Andel jankeesvanan...@gmail.com You can use the Selenium RC Server [1] to host the browser. You can then remotely invoke this server from your Maven build. The Maven build then doesn't need a browser. (but you're right, Selenium needs a browser *somewhere*) Regards, Jan-Kees [1] http://seleniumhq.org/projects/remote-control/ 2010/4/8 Matthias Wessendorf mat...@apache.org Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
You could note that in the proposal :) On Thu, Apr 8, 2010 at 8:28 AM, Jakob Korherr jakob.korh...@gmail.com wrote: Selenium seems to keep coming up here again and again, but the main problem about it is that you need a browser to run the tests and that is what we don't want. We want to be able to include the tests in every maven build and thus also on the apache build server and we certainly can't use a browser there. Regards, Jakob 2010/4/8 Jan-Kees van Andel jankeesvanan...@gmail.com You can use the Selenium RC Server [1] to host the browser. You can then remotely invoke this server from your Maven build. The Maven build then doesn't need a browser. (but you're right, Selenium needs a browser *somewhere*) Regards, Jan-Kees [1] http://seleniumhq.org/projects/remote-control/ 2010/4/8 Matthias Wessendorf mat...@apache.org Had a look at JBoss' Arquillian ? -Matthias On Thu, Apr 8, 2010 at 9:55 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi Mike, Thanks for the feedback. I did considered Selenium, but after some discussions we concluded that the testing should be done totally automated within maven and without a browser, so that excludes Selenium since it needs a browser running in order to work. Regards, Cosmin On Wed, Apr 7, 2010 at 8:57 PM, Mike Kienenberger mkien...@gmail.com wrote: I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [GSoC] Automated webapp tests
I'd like to recommend that you also consider Selenium as a test framework. On Wed, Apr 7, 2010 at 10:04 AM, Martinconi Cosmin cosmin.martinc...@codebeat.ro wrote: Hi, I also prepared an application proposal, that I submitted to Google and a wiki page: http://wiki.apache.org/myfaces/GSoC2010_AutomatedTests for the Automated webapp tests for MyFaces Core and extensions issue. You can find the Jira Issue at: https://issues.apache.org/jira/browse/MYFACESTEST-6 I would really appreciate any feedback and comments. Thanks, Cosmin
