Payday Loans Online Payday Loans Online

Todd Rothe : UI/UX Developer

it's pronounced rowth-ee

By 2g1c2 girls 1 cup

FlexPilot, Ruby, Selenium WebDriver, Jenkins and Windows Part 3

Recently I have been tasked with running automated tests against an html/javascript/flex app as part of the automated build.
This is part 3 in a series of posts detailing the flexpilot install, writing ruby tests, and configuring the jenkins targets and windows box to run the automated tests. The completed ruby test can be seen by viewing source, downloading the project and opening the SampleTest.rb on your local maching.

Part 3 – The FlexPilot API and robust tests in ruby.

Like most API’s the FlexPilot API is straight forward once you know how to use it.

Let’s start by running our SampleTest.rb in its current form (you can grab the contents from this text file).
Open a terminal window, cd to the location of SampleTest.rb, type ruby SampleTest.rb. When the test ends you should see the following in the console:
1 tests, 1 assertions, 0 failures, 0 errors
Notice ‘1 assertion‘. This is the assert_equal in our teardown method that informs us of verification_errors.

Let’s add a ruby test assertion to our test (weez about to get reeeeeeal).
On the last line of our test test_loadAndClickButton, replace the silly ‘sleep(10)’ with a useful assertion:
assert_equal(false, @driver.execute_script("return document.MyApp.fp_assertDisplayObject({name:'modalWindow'})") )
In true TDD fashion we write this test to fail by asserting ‘false’. Run the test and you should see the terminal output something like:
Finished in 16.473764 seconds.
1) Failure:
test_loadAndClickButton(MySampleTest) [SampleTest.rb:25]:
< false > expected but was
< true >.

Change the ‘assert_equal(false…‘ to ‘assert_equal(true…‘ and run the test again. You should see terminal output of:
Finished in 16.264205 seconds.
1 tests, 2 assertions, 0 failures, 0 errors

To examine our ruby test assertion:
assert_equal(val1, val2)
val1 = true (a boolean)
val2 = @driver.execute_script(“return document.MyApp.fp_assertDisplayObject({name:’modalWindow’})”) )

In val2 we leverage the @driver webDriver instance to execute the javascript @driver.execute_script(” “). It’s worth noting that this is the structure we use to communicate with flexpilot – webDriver executing javascript, flexpilot understanding and responding to javascript.
In this case the script returns a boolean value from the flexpilot api call fp_assertDisplayObject.
The fp_assertDisplayObject() method accepts one parameter object (see the curly braces in ({name:’modalWindow’}) ) called a locator. A locator object is simply a name/value pair. In this case the name is ‘name’ and the value is ‘modalWindow’. Note that name is declared without quotes but the value of modalWindow has quotes. In the future we will leverage the ‘automationName’ property in Flex to label and locate our displayObjects as much as possible.

If you see terminal output like this:
1) Failure:
test_loadAndClickButton(MySampleTest) [SampleTest.rb:25]:
< true > expected but was
< nil >.

Then you omitted the ‘return’ at the beginning of the javascript, like so:
@driver.execute_script(“document.MyApp.fp_assertDisplayObject({name:’modalWindow’})”) )
This tripped me up a few times as I was getting started.

def test_loadAndClickButton
@wait.until{ @driver.execute_script("return document.MyApp.fp_assertDisplayObject({automationName:'loginBtn'});") == true }
assert_equal(true, @driver.execute_script("document.MyApp.fp_assertDisplayObject({name:'modalWindow'})") )

Knowing what a locator is and how to use it is half the battle. You can see from the API doc that most methods require only a locator param.

Let’s look at the slightly more complex example of fp_getPropertyValue( locator, attrName).

Open your app and add the following line to MyApp.mxml.
< s:TextArea id="ta" automationName="myTextArea" text="sample"/>

In MyApp.mxml, parent the button and text area with a VGroup.

< s:VGroup>
< s:Button id="loginButton" automationName="loginBtn" label="Login" click="{'Zark Wad!')}"/>
< s:TextArea id="ta" automationName="myTextArea" text="sample"/>

Run the app and see our new text area appear.

In SampleTest.rb we are going to kill the button/alert test and instead test the height of the TextDisplay inside a TextArea component – which you might do if you wanted to ensure a block of text is displaying as expected (font, style, length, etc).
Replace the last 3 line of our test with:
@wait.until{ @driver.execute_script(“return document.MyApp.fp_assertDisplayObject({automationName:'myTextArea'});") == true }
assert_equal("100", @driver.execute_script("return document.MyApp.fp_getPropertyValue({id:'textDisplay',attrName:'height'})"))

Run the test and adjust the expected value (100 in the above sample) to match the actual value which is returned by the test failure:
1) Failure:
test_loadAndClickButton(MySampleTest) [SampleTest.rb:24]:
< "10" > expected but was
< "149" >.

To change the text displayed in the TextArea:
@driver.execute_script(“document.MyApp.fp_type({automationName:’myTextArea’,text:’this is the new sample text ‘})”)


No Responses to “FlexPilot, Ruby, Selenium WebDriver, Jenkins and Windows Part 3” (post new)


Leave a Reply

You must be logged in to post a comment.