mahara-contributors team mailing list archive

[Lisa Seeto <1897190@xxxxxxxxxxxxxxxxxx>]

** Changed in: mahara
       Status: New => In Progress

** Changed in: mahara
     Assignee: (unassigned) => Rebecca Blundell (rjb-dev)

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1897190

Title:
  Behat: Tidy up and improve behat properties file

Status in Mahara:
  In Progress

Bug description:
  Background:

  A while ago we set up a behat 'properties' file to hold css/xpath
  locators so they wouldn't need to be included directly in steps. When
  that was implemented, all the steps that included css/xpath references
  were taken out and replaced with the steps that call the properties
  file.

  The original idea was that as new things needed to be found by the
  test suite, they would be added to the properties file and it would
  gradually grow to cover more of the site.

  
  Now:

  Steps that call the css/xpaths directly have been appearing back in
  the tests, rather than being added to the properties file as they are
  needed. This is probably just because it is faster to not add the
  locator to the properties file and just call it directly in the test.

  
  Issues:

  1. Adding the locators directly to tests means they are harder to read.
  2. Currently the properties file is hard to read. It has different locators from anywhere in the site put into one array, so you can't easily see whether a locator for the item you want already exists.
  3. The properties file could use a refactor. We were supporting an old PHP without constant arrays and constant multi-dimensional arrays when it was written.
  4. It is faster to write a test with the locators directly than adding the locator to the properties file, so test writers may still not use it.

  
  Suggested solutions to issues:

  
  1. Refactor existing tests with css/xpath locators to use the properties file.
  2,3. Update the properties file so that it has different arrays or a single multi-dimensional array with sections related to components of the site, something like: 
  define ("HEADER", array (
    'Search'  =>'#usf_query',
    //more things
  ));

  define ("DASHBOARD", array (
    'Static pages' => "//a[contains(@href, 'site/pages')]/b",
    //more things
  ));

  define ("FOOTER", array(
    //more things
  ));

  define ("SIDEBLOCKS", array(
    //more things
  ));

  define ("BLOCKS", array (
    //more things
  ));


  4. Spend some time adding some more locators so they are covered and don't need to be added by the tester, as finding how to interact with an element is the slowest part of test writing.
  Consider the way the properties file is called. 
  - Is there an easier way than calling the properties steps? 
  - Could there be an underlying function that replaced passed in variables with locators called from all existing relevant steps? (Maybe that would create unnecessary overhead).
  - If there is a way that would make it easier to use the properties file from a dev/tester perspective, it will be used.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1897190/+subscriptions