Test Ocean

Usually we require to rerun the failed test cases again once they are fixed or for double verification.In cucumber we can do that easily without developing any customize code for it. Cucumber directly supports the feature to re- run the failed test cases as following: Run Cucumber with rerun formatter simply using :   cucumber -f rerun --out rerun.txt It will output locations of all failed scenarios to the file. Then you can rerun them by using cucumber @rerun.txt This can be further bundled as a rake task and can be run simply as : require 'cucumber' require 'cucumber/rake/task' Cucumber::Rake::Task.new(: jenkins_with_rerun ) do |t|   cucumber -f rerun --out rerun.txt   cucumber @rerun.txt end task :default => : jenkins_with_rerun  And then can be run as simply "rake" inside the project folder:   C:/>ProjectFolder>rake

While working in cucumber many times we find that some piece of code is redundant across multiple step definitions.To make this work a simple solution is callling a step from another step like: Given /^ I login successfully$ / step "I login with valid credentials" end But this approach is problematic from debugging perspective as in case of we need to debug the scripts as it will lead to only first level of step calling which will not be helpful for issues resolution. Somewhat better way to achieve re usability,robustness and clarity is to simply fall back on language basic primitives -methods.We may encapsulate these small defs inside a module and extract it to " World " and call the method directly from where ever required as below: #/support/world_extensions.rb module KnowsUser def login visit ( '/login' ) fill_in ( 'User name' , with : user . name ) fill_in ( 'Password' , with : user . passw...

Sometimes while automating we need to have  all checkboxes unchecked as a precondition or baseline state in a given page.We can do that in Cucumber/Capybara using following code: all ( 'input[type=checkbox]' ). each do | checkbox | if checkbox . checked ? then checkbox . click end end Similar logic can be developed for other types of objects if required or better object type and locator detail can be passed as parameters to achieve higher level of abstraction which will work for any type of objects.

Today I will share the code to handle dialog boxes using Cucumber . Assuming that you are using cucumber with capybara ,following code can be used: When /^ I confirm popup$ / do page . driver . browser . switch_to . alert . accept end When /^ I dismiss popup$ / do page . driver . browser . switch_to . alert . dismiss end Using the above generic code ,popups can be accepted or rejected as required. It utilizes the selenium webdriver API to handle that as capybara is simply calling the Selenium API. This can be handled directly using selenium webdriver as below: require "selenium-webdriver" driver = Selenium :: WebDriver . for : firefox driver . navigate . to "http://mysite.com/page_with_alert.html" driver . find_element (: name , 'element_with_alert_javascript' ). click a = driver . switch_to . alert if a . text == 'A value you are looking for'   a . dismiss else   a . accept end

I will Show you how to  filter and run the cucumber tests by using the master driver script.We will use the following components for this as below: 1).YML based Configuration File ************************************************************** env_1:   Priority : p1 ############## ApplicationData:       ResultsPath : "D:\\TestProject\\Results"       FeaturesFolderPath : "D:\\TestProject"       ResultFormat : "html" *********************************************************************** This file will help us in providing the following info: a).Tag Filter "p1" by which we can execute only high priority test scenarios. b).Results Path Folder c).Features folder path d).Desired Result Format 2).Master Driver Script(Driver.rb) ******************************************************************************** #Importing the required libraries require 'yaml' require 'FileUtils' #R...

Basic Example import unittest from selenium import webdriver class Login ( unittest . TestCase ): def setUp ( self ): self . driver = webdriver . Firefox () def tearDown ( self ): self . driver . quit () def test_login ( self ): driver = self . driver driver . get ( 'http://testurl' ) username = driver . find_element_by_name ( 'user_id' ) username . send_keys ( 'admin' )     Selecting element from drop down list el = driver.find_element_by_id( 'id_line' ) for option in el.find_elements_by_tag_name( 'option' ):      if option.text = = "line to select" :          option.click()          break Verifying Table Values #Importing selenium webdriver library  from selenium import webdriver #Creating an driver instance of Firefox browser driver = web...

We will introduce today Capybara an higher level ATDD testing framework which support for multiple backends, supports Selenium and works in multiple browsers. The advantage of using Capybara over selenium is being on higher level than selenium , it can be used for other types of automation beside browser automation without changing the user facing simple and intuitive DSL. Let’s take for example a simple scenario of typing strings to an input textbox: Selenium-webdriver snippet require 'selenium-webdriver' element = driver.find_element :name => "q" element.send_keys "Cucumber tests" Capybara snippet require 'capybara' fill_in "q" , "Cucumber tests" The difference is clear in terms of simplicity and user friendliness which sets apart capaybara from selenium webdriver.Below is complete example for the reference starting from setting up the folder structure. I. Base Folder ...