Search code examples
ruby-on-railsrubyseleniumpage-object-gem

Ruby Selenium Webdriver + Page object model + Practice Website?


I have been using Selenium web-driver with java + TestNG framework, however, i've landed a job but they use ruby + selenium web-driver and the page object model. I've searched google and gathered some resources to read through before I start, however I would like to practice. From my understanding I could be completely wrong but for the page object model you create objects in a separate class which hold the same property's as the actual objects and then you use a different class with test code to test against those objects?

I would like to practice and learn from ground up does anyone know of some concrete tutorials for ruby with selenium? I used http://toolsqa.com/ for learning in java which was excellent something like this but in ruby would be great?

And the last question! I was testing in a work environment with local environments, What is a good public website that has a registration, login, etc that I could practice writing tests for?

Thanks


Solution

  • Rather than focus on specific frameworks it sounds like you need more information about the theory behind the Page Object Model Pattern in test.

    A High Level Overview

    One of the problems with writing automated UI tests for a website is there isn't a clear separation of concerns between the UI Logic and the Test Logic. The Page Object Model Pattern aims to solve this by separating your Tests into there own test classes which contain just test logic (e.g. asserts, application flow). And page object classes contain interactions with the page (e.g. clicking buttons and filing in forms on the page).

    A Page Object - In More Detail

    These classes are a representation of a 'page' which isn't just a standard webpage but could also mean part of a page or a modal dialogue box.

    They only contain how to do things on the page for example:

    • Click buttons
    • Fill in a form
    • Get elements from the page.

    Typically they are written as a Fluent Interface

    Imagine a app with a homepage and a contacts directory to search for contacts. This would be two page objects. A Homepage page object and a ContactsDirectoryPageObject. Each object handling how to interact with the page to perform actions and get data. So some puesdocode might look like:

    # The Homepage Page Object
    class HomepageObject {
    
      ClickContactsDirectoryPageButton()
      {
         webdriver.click(By.Id("contactsDirectoryButton"));
      }
    
      GetContactsDirectoryPageObject()
      {
        return new ContactsDirectoryPageObject()
      }
    }
    
    
    # The Contacts Directory Page Object
    class ContactsDirectoryPageObject {
      SearchForContact(contactName)
      {
        webdriver.findElementById("searchBox").Click().SendKeys(contactName)
        webdriver.findElementById("search").Click()
      }
    
      GetFoundContactInformation()
      {
        resultElement = webdriver.findElementById("result")
    
        # Some logic to convert element into a model to pass back
        result = new ContactResultModel(resultElement);
    
        return result;
      }
    }
    

    Using Page Object in test

    so when used in a test class they might look like (puesdocode):

    class MyTest {
    
      daveContact = homepage.ClickContactsDirectoryPageButton()
                            .GetContactsDirectoryPage()
                            .SearchForContact("Dave")
                            .GetFoundContactInformation()
    
      Assert.That(daveContact.Name).Equals("Dave")
    
    }
    

    Now the test only does one job - asserting that the feature under test works. By working through the application and asserting on data from it. The test doesn't know anything about how the page is constructed out.

    Why Bother (Advantages)?

    • If your tests contained both test logic and page object model logic then you would have to update all your tests every time the ID of a button or text box changed.
    • The tests become easier to read as they just focus on mapping out the flow of the app and asserting it is correct.
    • Updating your tests when the application changes is easier as you only have one place to update it - your page objects.