• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Wonder-disc] ERSelenium without ERExtensions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: [Wonder-disc] ERSelenium without ERExtensions
      • From: Denis Frolov <email@hidden>
References: 
 >Re: [Wonder-disc] ERSelenium without ERExtensions (From: Chuck Hill <email@hidden>)
 >Re: [Wonder-disc] ERSelenium without ERExtensions (From: Steven Mark McCraw <email@hidden>)
 >Re: [Wonder-disc] ERSelenium without ERExtensions (From: Chuck Hill <email@hidden>)
 >Re: [Wonder-disc] ERSelenium without ERExtensions (From: Michael Bushkov <email@hidden>)
 >Re: [Wonder-disc] ERSelenium without ERExtensions (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: [Wonder-disc] ERSelenium without ERExtensions
  • Next by Date: Re: [Wonder-disc] ERSelenium without ERExtensions
  • Previous by thread: Re: [Wonder-disc] ERSelenium without ERExtensions
  • Next by thread: Re: [Wonder-disc] ERSelenium without ERExtensions
  • Index(es):
    • Date
    • Thread