Re: [Wonder-disc] ERSelenium without ERExtensions
Re: [Wonder-disc] ERSelenium without ERExtensions
- Subject: Re: [Wonder-disc] ERSelenium without ERExtensions
- From: Michael Bushkov <email@hidden>
- Date: Sat, 30 Jun 2007 15:08:23 +0400
Hi Chuck,
Chuck Hill wrote:
The advantage of this approach is that you don't need to do test source
code postprocessing. The same source code will be equally processed in
selenium-ide and on any host where ERSelenium is used.
Besides Selenium-RC looks like a kind of overkill solution to us, so we
try to avoid it and use only selenium-core, which is much more simple
and easier to install and use.
Why does it look like overkill to you?
It requires installation of the Selenium-RC server on the test platform.
This means that I can't run the test from the dozen of different
browsers on the dozen of different platforms - even If I want to, I'd
need to install selenium-rc everywhere.
Selenium-rc allows the tests to be actually written in the real
programming language. I'm sure that most of the test cases don't use any
flexibility allowed by generic programming language.
Selenium-rc allows a workaround over same-origin policy. But while
developing WO app you actually don't have to search for such a
workaround - because as you need to host the app somewhere, you can
easily host the selenium-core in the same place.
So, while allowing the set of features, mostly equal to the
selenium-core, selenium-rc introduces a new layer of complexity above it.
Of course the ERSelenium's approach (mostly similar to
selenium-on-rails) introduces it too, but it's idea is to rely solely on
selenium-core while adding some tests-sources-processing features and
handling testing results.
And I'm not an XPath admirer, but it can sometimes be
extremely useful:
|select|xpath=//label[contains(string(),'Payment
type')]/following-sibling::div/select|By cash*|
This will select "By cash" option in the listbox next to the "Payment
type" label.
But that assumes that you are using the HTML label tag. In my
experience that is not a commonly used tag. So you end up either having
to retrofit label tags or IDs in existing applications (or using really
hard to read Xpath expressions).
Label is in fact a semantic W3C recommended way of dealing with form
labels, but anyway this is a specific test for a specific website. As
'label' tag was used in that website, it's ok (IMHO) to use it in the
test. I mean that each test should be written individually for the
project that it aims to test. So if that website used another 'div'
instead of the label tag, then we'd write the test as follows:
|select|xpath=//div[contains(string(),'Payment
type')]/following-sibling::div/select|By cash*|
How do you handle "clicking" on component action links?
We try to use "link" locators and simple xpath where possible:
|clickAndWait|link=Return Hat||
and
|clickAndWait|//button[@value='Next']||
Here is also the ugly, but powerful example from the BugTracker's set of
tests (I guess it's the only way there to emulate clicking on the
'Comment' link in the '__SeleniumBugSubject' bug's row):
|clickAndWait|//td[contains(text(),
'__SeleniumBugSubject')]/parent::*/preceding-sibling::tr[position() =
1]//a[text() = 'Comment']||
Such kind of xpath is actually common when testing D2WList-driven pages
with no additional code for generating ID attribute for links.
In my tests, I often have a series of 3 - 7 tests that need to be run in
order. I also have larger "groups" where the tests in each group can be
run in any order but the groups have an order (e.g. need to setup the
users before running the user login tests).
To do this kind of thing we have:
- A separate test, that tests the whole process of user registration
- An action method that ensures that the 'test' user is registered
- The test that tests the login procedure that uses the above action
method to ensure that the needed user exists
- A setup method that ensures that the 'test' user is registered and
already logged in. All tests that need the 'test' user to be logged in
use this method.
With this approach each test checks some independent bit of
application's logic and can be run without dependency on other tests.
We used approach similar to the one that you describe, but later decided
that the required ordering of tests is driven by the lack of setup
methods. Besides, look at the beginning of the typical test:
|open|/wa/SeleniumAction/resetSession||
|assertTextPresent|Action command succeeded.||
|open|/wa/SeleniumAction/ensureTestAdmin||
|assertTextPresent|Action command succeeded.||
These lines ensure that the user with admin rights is registered in the
system. With this style of writing test, not only they become
independent, but their sources become self-explanatory.
Setup/teardown actions are also helpful when you need to clean up after
your testing activity. Sometimes we run our tests against application in
productioni mode (note, that we don't have to install anything other
than application itself and ERSelenium framework to do that). In this
case cleaning up is a must.
Testing in production may sound dirty but in fact it is quite useful
since production environment (database schema and content, webserver
resourses, ip address, etc) may differ from test one and testing can
give you additional confidence in your app.
Actually your approach is a kind of alternative to what we use, and it
can be easily supported by ERSelenium. At least it can be more or less
supported by naming-in-alphabetical order tricks (this should work both
for individual cases and for test suites), but I'll think of more
specific support.
There should also be a WO-specific workaround that will allow using file
uploads in Selenium tests in any browser. It's a good candidate for my
TODO list.
I think you will find this impossible without a chrome type of hack.
JavaScript is prohibited from doing this for security reasons. If you
do succeed, I'd like to hear about it! :-)
If I find some dirty hack, I'd certainly tell you :)
--
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden