Mike just to give a short intro if you look at this example
https://gist.github.com/1271104
You see basically an example with one testgroup and one testcase
What happens here is that a testgroup is specified which can hold one or
more testcases
and a simple ajax textcase is specified, with the default behavior.
What happens is
a) Internally a setup method is called which sets the system up
it is overwritten in this case.
b) a precondition method is called (currently not overwritten)
if this method returns false then the test has failed and the execution
on the test is stopped
c) a run method is called which performs some runtime operation, in our
case the ajax call is started
d) a postcondition now is called after the ajax cycle has successfully
completed which does the asserts
e) a tearDown method is called internally
Any error from the ajax side also would make the test fail
Most of the tests follow this pattern, some inherit the standard
testcases to adjust the control.
Currently the tests simply are analyzed on group level and the logging
output and final result of each group test are put into the browsers
console and a console logging area.
I will refine the API more now that I know other people are interested,
but let me finish the server side statisitics collector first.
Then I will stabilize the api, I am in some aspects still not quite
happy with it. So expect some changes in the upcoming 2-3 weeks.
Werner
Am 10/7/11 4:16 PM, schrieb Mike Kienenberger:
Werner,
Well, I think I've answered my own question regarding the maven issues
-- changing the version from 2.1.4-snapshot to 2.1.3 makes things
work.
One thing I noticed is that your starting link location of
"http://localhost:9080/TestScripts/"; seems to be a broken link. Using
http://localhost:9080/ and going from there seems to work.
On Fri, Oct 7, 2011 at 10:03 AM, Mike Kienenberger<mkien...@gmail.com> wrote:
Hi Werner.
Since I have had a lot of "wait" issues with ajax + Selenium testing
my own JSF apps, I tried to take a look at what you were doing to see
if I could write my own app jsf tests using your new framework.
However, I am getting the following installation/build errors. I'm
still on ant as I've never taken the time to learn the intricacies of
maven, so I'm not sure what needs to be done to fix them. I'm
guessing it's because snapshot files don't exist in the public
repositories? So I'd either need to build my own snapshot files and
install them as directed, or re-point maven to a specific released
build version?
Also, am I right in thinking your framework can be used for generic
JSF app testing? Or is that some future goal not yet achieved?
1) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT
[...]
Path to dependency:
1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT
2) org.apache.myfaces.core:myfaces-api:jar:2.1.4-SNAPSHOT
2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT
[...]
Path to dependency:
1) com.mycompany:IntegrationJSTest:war:1.0-SNAPSHOT
2) org.apache.myfaces.core:myfaces-impl:jar:2.1.4-SNAPSHOT
On Fri, Oct 7, 2011 at 4:36 AM, Werner Punz<werner.p...@gmail.com> wrote:
Thats what I am working on, my personal idea is, to run the tests and then
have a final result page which then can be analyzed by selenium.
Hence i was talking about having a server side statistics collector which
collects all the results over all pages.
It simply is better to have the tests themselves performed by javascript
because there you can deal better with the dom and with the jsf lifecycle.
In Selenium you only can issue wait ... seconds wheras
my tests directly can intercept the jsf lifecycle with listeners.
Werner
Am 10/7/11 10:30 AM, schrieb Mark Struberg:
I see.
Is there a way to kick this tests with Selenium? Of course only with
firefox - but better than nothing ;)
LieGrue,
strub
----- Original Message -----
From: Werner Punz<werner.p...@gmail.com>
To: dev@myfaces.apache.org
Cc:
Sent: Friday, October 7, 2011 10:14 AM
Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache
extras
T here is one small reason. The tests run directly in the browser instead
of htmlunit (which has a lot of bugs, hence I shun it i already
had two adjustments regarding it in other tests)
So how do we run the tests in maven in 5 different browser engines,
three of them being windows only.
Dont get me wrong htmlunit is nice, but it does not give reliable
results when it comes to javascript and emulating browser quirks.
Thats the only reason.
Werner
Am 10/7/11 9:42 AM, schrieb Mark Struberg:
woha, big +1 and thanks for the hard work.
Btw, why not hosting it directly over here as a test module for MyFaces
core which could get executed before doing releases?
LieGrue,
strub
----- Original Message -----
From: Werner Punz<werner.p...@gmail.com>
To: dev@myfaces.apache.org
Cc:
Sent: Friday, October 7, 2011 8:57 AM
Subject: Re: [ANN] MyFaces jsf.js integration tests hosted on apache
extras
Am 9/29/11 9:35 PM, schrieb Werner Punz:
Hello everyone, I just wanted everyone to know, that I am
currently in
the process of cleaning up and dumping my jsf.js client side
javascript
integration tests collected over the last year onto apache
extras.
The project is hosted at
http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/
and can be checked out via git. It is by far not done yet, so far
i have
converted about 20% of my usually manually run javascript tests
to a
small ajax jsf specific testing framework and also some server
side
statistic collection has yet to be done but you already can have
a look.
This project also in the future will be my primary workbench for
the
javascripts before merging them into the trunk and branches.
You already can have a look and run the tests, the explanation
can be
found on the projects site.
Werner
Hi Just a short status update, I now have about 20 tests checked in
with
13 testgroups. I also added Mojarra as optional test target. I found
promptly three bugs, which I will forward to the Mojarra guys in the
next week.
The only stuff pending now is some cleanup and a server side test
statistic so that we can get the test results into a final result
page.
