Investigate how CukeFarm should support providing Page Objects and helper functions access to the World

[thompsnm]

The World section of the Cucumber.js README demonstrates two ways to set the World that will later be provided to Steps. CukeFarm is hard coded to follow the first example: telling Cucumber.js to instantiate a World object. This means that only the Steps have access to the World out of the box, which causes issues if you write helper functions or Page Objects that also need access to properties on the World. The following questions should be answered by this ticket:

1. Should CukeFarm support the second example: providing an object and telling Cucumber.js to use it as the World?
2. Should the CukeFarm Step Defs that instantiate Page Objects be modified to pass the World object by default?

Expected outcome of this issue:

• If the answer to question 1 is Yes, a new issue should be filed to add the described functionality.
• If the answer to question 2 is Yes, a new issue should be filed to add the described functionality.
• If the answer to both question 1 and question 2 is No, no further work is needed.

Note:

• The current best practice for providing a Page Object access to the World is to define a new Step Def in your project that passes the World to the Page Object's constructor when it is instantiated.
• The current best practice for providing the World to helper functions that are used by Step Defs is to use the Function.prototype.call() function when calling such helper functions in a Step Def. This will allow you to set the scope of the helper function to that of the Step Def. In this way, the syntax of the helper function can match that of the Step Defs.

[wyvern8]

Any further thinking in this area?

[thompsnm]

Sorry, as evidenced by the most recent timestamp on this issue, it really hasn't been prioritized. Glancing back at the World section of the Cucumber.js README, as linked from the initial issue description, they don't show the second example as I referenced it. See here for the README as it looked at the time. Given that functionality is, at the least, not advertised I would say the answer to question 1 above would be no, we should not try to support providing Cucumber.js an object to use as the World.

As far as question 2 is concerned, I can't honestly say I remember the use case that prompted it. I'm curious what situations would justifiably require passing the full World object to a page object. It seems that to keep the code more modular, it would make more sense to structure the functions on page objects to accept only the relevant data as parameters and then simply pass the properties on the World object to the functions when they're invoked in the Step Defs. This is contradictory to the "current best practice for providing a Page Object access to the World" as listed above and would not necessitate modifying the existing CukeFarm Step Defs.

@wyvern8 , I'm curious about your perspective since you brought it up. Have you encountered cases where you felt the current best practices didn't support your process?

[thompsnm]

As an interesting aside on best practices, a little research turned up this blog post in which the author advocates for moving all Step Def helper functions to separate files and then including those in the World definition, which would be an alternative to the "current best practice for providing the World to helper functions that are used by Step Defs" as listed above.

[wyvern8]

Hi @thompsnm . I started thinking along these lines for helper functions shared across page objects. At the moment I am just pulling in a pageutils module in each page object, however it seemed that perhaps the world object should be providing access to utils - similar to how the elementhelper etc is available in step defns.

Also, I was wondering whether page objects should be able to set state attributes when they are instantiated. It seems that the world object is generally where state attributes are held if required to be shared across steps (although it is also usually the steps that would set them). Without access to the world in page objects we may need to use custom steps in some cases when we want to set state attributes, which could imply creating alternate versions of some cukefarm step defns. I don't have a specific use case for this right now, but it could be something like configuration referred to in step defns that changes depending which type of page object is current - eg a timeout value. Perhaps this is a bad pattern, and it is closed off intentionally :)