Thought it might be useful to add something to the mix of technologies: FIT + WebDriver
FIT is a tool that lets you specify tests in human-readable html. We have non-technical business analysts who help to construct our acceptance tests. We've wrapped WebDriver with simple, fairly generic, FIT fixture, so that our BAs can say things like:
into Country select box select United Kingdom wait for Language label to contain English (the Queen's) click Save button
We've found that pretty much anyone can read this stuff, and once you have the basic fixture in place, you can describe most interactions fairly easily. Some things we found valuable:
* Let the users describe stuff in their own (businessy) words. We declare all the nouns ("Save button", "Country select box") as name value pairs, and just use xpath/ids to grab a handle to the DOM object in WebDriver.
* It is nice to have a SetFixture to check all elements described by one of our nouns ("Text fields in address form"). Then we can check all the standard attributes, but especially name and value.
* Users don't really care about CSS classes. We use non-generic fixture to wrap concepts we have customised, such as "disabled" and "hidden", both of which have patchy support in WebDriver.
* AJAX calls need a corresponding "wait for" assertion, so that you know the call has returned (if the next step in your test makes assertions about the result). Users don't really care about this either ("It happens really fast on the screen, why is the test different?") but tough - they are specifying an asynchronous app.
However, at my job, we use Selenium with a custom user-extensions.
For example, if I have an input like: _td_Name:_/td_ _td__input id="textInput" type="text"...__/td_
I prefer to have a locator of the type: inputLocator="Name:" than: id=textInput
The idea behind is to have tests that can be understood without having to know the underlying HTML. In theory, everybody should be able to read your test and understand that you enter a value in the 'name' input. I encourage people to write tests that are like human actions (click on the checkbox near a given text, or check a cell in a table where the column name is...).
Of course, this method lead to some problems when you have a multilingual site, since all the text locators need to be translated.
Oh, and we save the page when the replayer finds an error. This way, we can quickly check the error by loading the saved page, instead of replaying the whole test.
This comment has been removed by the author.
ReplyDeleteThought it might be useful to add something to the mix of technologies: FIT + WebDriver
ReplyDeleteFIT is a tool that lets you specify tests in human-readable html. We have non-technical business analysts who help to construct our acceptance tests. We've wrapped WebDriver with simple, fairly generic, FIT fixture, so that our BAs can say things like:
into Country select box select United Kingdom
wait for Language label to contain English (the Queen's)
click Save button
wait for url to contain some.new/url
assert description box contains colour
assert description box contains flavour
assert description box contains dialogue
We've found that pretty much anyone can read this stuff, and once you have the basic fixture in place, you can describe most interactions fairly easily. Some things we found valuable:
* Let the users describe stuff in their own (businessy) words. We declare all the nouns ("Save button", "Country select box") as name value pairs, and just use xpath/ids to grab a handle to the DOM object in WebDriver.
* It is nice to have a SetFixture to check all elements described by one of our nouns ("Text fields in address form"). Then we can check all the standard attributes, but especially name and value.
* Users don't really care about CSS classes. We use non-generic fixture to wrap concepts we have customised, such as "disabled" and "hidden", both of which have patchy support in WebDriver.
* AJAX calls need a corresponding "wait for" assertion, so that you know the call has returned (if the next step in your test makes assertions about the result). Users don't really care about this either ("It happens really fast on the screen, why is the test different?") but tough - they are specifying an asynchronous app.
www.vrtex.blogspot.com
ReplyDeleteI completely agree with Chris.
ReplyDeleteHowever, at my job, we use Selenium with a custom user-extensions.
For example, if I have an input like:
_td_Name:_/td_
_td__input id="textInput" type="text"...__/td_
I prefer to have a locator of the type:
inputLocator="Name:"
than:
id=textInput
The idea behind is to have tests that can be understood without having to know the underlying HTML.
In theory, everybody should be able to read your test and understand that you enter a value in the 'name' input.
I encourage people to write tests that are like human actions (click on the checkbox near a given text, or check a cell in a table where the column name is...).
Of course, this method lead to some problems when you have a multilingual site, since all the text locators need to be translated.
Oh, and we save the page when the replayer finds an error. This way, we can quickly check the error by loading the saved page, instead of replaying the whole test.